Agile Manifesto, the Twelve Agile Principles

This post reviews the Twelve Agile Principles and provides some evaluation, opinions and additional information, from experience, about the Principles. In addition, where applicable, this post ties these Principles back to the relevant industry best practices.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Agile supports a continuous cycle of planning, requirements, design, development, testing and deployment by delivering agreed upon software (i.e., every couple weeks or months) using an incremental approach. Keep in mind prior to the requirements being implemented they should have been approved by the stakeholder(s). Once requirements are approved they should be assigned a release or sprint and completed as outlined in the project plan. In addition, the quality of the software and whether or not it contains the functionality asked for all play a role in the customer’s satisfaction. As I mentioned in an earlier post, you can give the customer quick turn-around times and even software with a savvy user interface. However, if the software doesn't provide the functionality the stakeholder needs; the stakeholder won't be satisfied. Lastly, using a software design that meets industry best practices also ties into customer satisfaction. Here are a few points to keep in mind:

• Add requirements to a tool that enables the Business Analyst (or Systems Analyst) to indicate whether a requirement is approved or not approved. User stories can and should be traced just like use cases so they are grouped by feature.

• For software to satisfy the customer it must be sufficiently tested. Testing should verify that the requirements are implemented as stated. And, testing should also verify that the software product works. In other words, does the software have defects that will make users complain and cause the primary stakeholders to, ultimately, be unhappy?
• The software design must be scalable and maintainable. This aspect of software is so important. I supported a project once where the software design for the reporting component of a business application was far more complicated than it should have been. Instead of using Crystal Reports or other similar reporting software the vendor wrote lines and lines of code that took months to complete. Needless to say, it was very difficult for the customer to maintain and update the software, which made the customer very dissatisfied.

 

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

This principle directly ties to the first principle. If a stakeholder voices a need for a requirement change; it is definitely up to the technical team to meet that need. Although, keep in mind, the technical team typically cannot tell the stakeholder whether or not a requested change provides a competitive advantage. And, a stakeholder may not stop to assess whether or not a change provides a competitive advantage. Most often, when a stakeholder wants a change implemented--it's implemented. Interestingly, over the years I have seen requirements change for many reasons. For example, I was hired by a company whose entire technology team told me the stakeholder couldn’t make up his mind. They said the requirements never made it to development. I met and talked with the stakeholder knowing the problem couldn't possibly be as bad as they said. I documented the requirements as he stated. Then I created the requirements document. The stakeholder reviewed the document. He then changed everything we had discussed.  We went through about four revisions of the document when I finally decided to try something different. Instead of continually rewriting the documents I decided to create UML (unified modeling language) diagrams, navigational flow diagrams and user interface (UI) mockups for the software product. I showed him the diagrams and the UI mockups. He made his changes on the diagrams and the mockups. I updated the diagrams and showed everything to him again. He approved them. I then used the diagrams and mockups to update the requirements documents. He signed off on the requirements documents and development began.  In this situation, the stakeholder was more of a visual learner and the text wasn't giving him the clarity he needed to make a firm decision. Lastly, if requirements are changing it is possible that the Business Analyst will need to generate an impact analysis report. The impact analysis report can then be used to see whether or not dates will need to shift because of the changing requirements. 

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

I supported a project where the Information Technology Department went through the entire cycle and completed a software product. During the walk-through (where the IT team showcased the system features) the IT team was told the software was not what was needed. Millions of dollars were just wasted building something the organization didn't need--all because the requirements were wrong. There is certainly value in implementing a business application using an incremental approach. Keep in mind that the team still performs the planning, requirements, design, development, testing and deployment. However, the team picks a much smaller scope of works for the Business Analyst to work on. Once the BA has completed the smaller scope of work that work is then passed on for design and so on. The BA then starts working on gathering requirements for the next scope of work. A continuous cycle is followed until the project is completed. By focusing on completing smaller scope of requirements, the team completes a smaller scope of work iteratively so the customer is continuously seeing updates to the product. These updates may be every two weeks or more; but should not be more than two months.

4. Business people and developers must work together daily throughout the project.

Depending on everyone’s workload this Principle may or may not be feasible. At a very large agency where everyone is very busy we met daily for about ten minutes. However, we only did this once development started. Project planning was limited to the people needed to plan the project including the technical team and the product owner. Requirements gathering sessions included the stakeholders and the technical team. The daily ten-minute status meetings were held once development started. The objectives of the daily 10-minute status meetings were to accomplish the following:

a.     Understand what issues technical team members were having,
b.     Understand what barriers needed to be removed, and
c.      Assign action items to those who could fix the stated problems.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Every decision most organizations make is done so with their overall business objectives in mind. For example, an organization has a Time Keeping System that three departments use for billing and cost management. The Time Keeping System supports business objective 3. Manage costs and implement projects within budget. On the other hand, everyone uses the corporate intranet to read the latest news about the company. The corporate intranet meets a lower business objective that aims to keep everyone informed. The organization will approve the Time Keeping System project. To execute this principle, the organization would look for its most highly motivated people. These are the people that always get things done with little or no prompting. They always meet their timelines. These people also initiate solving problems without being asked. If an organization seeks to build its projects around these types of people, the project will most certainly meeting its timelines.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Face-to-face is the best way to communicate because you can "see" if someone is puzzled or doesn’t understand a question. And, I've seen quieter individuals gain motivation to speak up from the more talkative participants. However, if face-to-face is not always feasible (because people live in different parts of the world or schedules are too hectic) meet face-to-face as often as you can. When it isn't feasible to have an in-person meeting there are two other approaches that can be used as follows:

• Microsoft Office Lync supports video conferencing, desktop sharing and chatting.
• Microsoft Office SharePoint 2013 includes an updated My Site component that delivers a much stronger collaboration experience to help teams work more closely together regardless of location or schedule. Microsoft Office 365 offers SharePoint Online, which can be less costly to implement than the non-cloud version of SharePoint.

7. Working software is the primary measure of progress.

It is a good practice not to get excited when the documents are written or the software is in testing. The real measure of progress is when the working software has been delivered. And, any release notes, training, user documents, etc. agreed upon are also delivered along with the working software. Again, the software should have been developed from stakeholder-approved requirements assigned to the release or sprint.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

For those of you who have ever implemented the complete Rational Unified Process (RUP), you probably can appreciate this Principle. Although, for some projects the complete RUP is needed because of the software project and the organization's business. For other software projects the complete RUP may be too much. If this is the case, the organization may implement a customized version of RUP, which I helped many organizations do. Or, the organization may benefit from a different Agile methodology that enables the project team to define and implement small scopes of functionality.  If the project does implement an Agile methodology the activities should not be so intense and the scope of work so big that it takes over two weeks (or two months) to complete. Instead, the activities should encourage the team to do exactly what is needed to complete the work accurately and remain within budget, timeframe and scope. This approach should enable the team to consistently complete a scope of work within the given timeframe. And, the team should always be able to deliver quality work because the work processes have been simplified as much as possible.

9.  Continuous attention to technical excellence and good design enhances agility.

A poorly designed software product is more difficult and costly to maintain than a software product with a good design. One of the most popular features of a good software design is reuse. Software reuse enables teams to accomplish more in a shorter period of time because code is reused. However, to reuse code takes planning from an organizational stand point. This is because code must be designed and developed properly for it to be reused. Many organizations are turning to using web services because developers can easily discover and reuse components. And, a web service can be shared across any platform. A second popular feature of good software design is usability. Microsoft says a software product has a good design if it is both simple and powerful. The article titled Power and Simple says an application is perfectly designed when there is the right balance of features and all unnecessary elements have been removed.(Microsoft's Simple and Powerful software design article can be accessed from the following link: http://msdn.microsoft.com/en-us/library/windows/desktop/aa511332.aspx)

10.  Simplicity--the art of maximizing the amount of work not done--is essential.

This Principle speaks for itself. Basically, use the simplest and most efficient way to complete the work that remains (after all, there is nothing you can do about work already completed). Most organizations looking to shorten the work cycle will most likely find a more practical way to perform project planning and requirements management (looking at ways to efficiently and effectively manage requirements without writing lengthy documents). Most organizations do not want to cut development or testing because of the inevitable consequences. Deployment is usually straight forward, if it pertains to a web application. Notifications are sent to the end users; the web application files are uploaded to the web server; and, the database is updated.

11.  The best architectures, requirements, and designs emerge from self-organizing teams.

The self-organizing team concept empowers people to do their jobs and make decisions about how they do their job. If you are a Business Analyst, for example, and the project manager is telling you how to gather requirements and manage them you are not part of a self-organizing team. The following link provides a great article on self-organizing teams: http://scrumalliance.org/articles/466-selforganizing-teams-what-and-how

 

12.   At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Ongoing self-improvement really should be every team member’s goal to become the best at what they do. A very effective concept used to help IT teams improve is called Lessons Learned. Through Lessons Learned sessions the team looks at its processes including what it did well and what it did not do well. The team also looks at areas in which it could have performed better. In addition, the team determines if the product met the stated requirements and if not, why not. And, the team assesses whether or not the customer was happy with the delivered product and if not, why not. These are just a few of the areas reviewed during a Lessons Learned session. Following is a useful link outlining best practices for Lessons Learned: Https://confluence.cornell.edu/display/CITPMO/Facilitation+of+Lessons+Learned+Discussions

Two Important Scrum Artifacts

Scrum is a framework that compresses Software Development Life Cycle (SDLC) activities in to shortened projects called Sprints. With Scrum a Sprint typically lasts 30-days or less.  This article looks at two important artifacts used by the Scrum team during a Sprint:  The Product Backlog and the Sprint Backlog.

The Product Backlog

With Scrum, one of the most important meetings is the Sprint Planning Meeting. Prior to this meeting the Product Owner works with the Business Analyst or Systems Analyst to define the features and dependencies associated with the business application to be developed or updated.

The Analyst works with the Product Owner and/or other stakeholders to understand key requirements for the business application including whether the software product is to integrate with other products. And, if integration is necessary what are the names and brief overviews of the applicable product(s).  Also, as part of the Vision the Product Owner discusses who the users are, the business needs and the problems the completed solution is to address. One of the key artifacts developed from these requirements gathering sessions is the Product Backlog.  The Product Backlog includes a list of the features, justification for each feature, dependencies, value rating, the risk associated with implementing the requirement and the priority. The risk is typically associated with the complexity of the requirement to be implemented. For example, developing an interface between two different systems is riskier than building a component used to generate reports. The priority will be used to decide what requirements are implemented for each Sprint. This means, typically High requirements are implemented before Medium requirements. And, Medium requirements are implemented before Low requirements.

Draft of the Product Backlog Artifact

The above picture is a sample initial draft of a Product Backlog for an imaginary Help Desk Management System project. The Development Team is expected to rebuild an existing Help Desk System because the technology is outdated and the system lacks many features that would help the Help Desk team provide improved support.

The Sprint Planning Meeting

Once the initial Features are defined the Business Analyst or Systems Analyst meets with the Product Owner and other assigned stakeholders to gather more detailed requirements. The Analyst is asked to document user stories and notes for the first 5 user stories, which the Product Owner hopes can be completed during the first Sprint.  During the Sprint Planning Meeting the Product Owner plans to circulate the Product Backlog and ask everyone to focus on user stories US1.1 – US1.5.

The Product Owner wants to make sure discussions remain within scope for the project. And, the Product Owner wants to make sure the team has a firm starting point so the meeting is structured and everyone is on the same page regarding the direction of the Help Desk System for the first Sprint.

Lastly, to me this group has a challenge. This is this group’s first Scrum meeting. Since this project does not have past information to lean on, the Product Owner has asked each team member to discuss issues, concerns, lessons learned, etc. from past projects.  This provides additional insight the Scrum Team can use to guarantee the success of the Help Desk Management System Project.

Product Backlog

Creating the Sprint Backlog

With the Product Backlog available for review along with the user story index cards, the team is ready for a productive Sprint Planning Meeting. During the Sprint Planning Meeting each member of the Development Team brings expertise to define all tasks that must be completed to make the Sprint a success. Everyone will review all of the work that must be completed to implement the five user stories before agreeing to the work.

Over the course of the Sprint Planning Meeting the Development Team (including the Web Developers, Systems Administrator, Database Administrator, Testers, Deployment Manager, Technical Trainer and Technical Writers (or any variation of these roles depending on the organization and project type (i.e., commercial or government))) provide input, as applicable. The objective is to come up with an artifact that catalogs all of the work that must be completed to fully implement the requested scope of user stories. The person in the meeting taking minutes will create a list of all the tasks and the name/title of each person stating the task(s) he/she must perform to help complete the work. This is the Initial Task List discussed in my previous article titled Agile User Stories & Test Cases.

Sprint Backlog

Once every task is accounted for, the team has the information needed to create a draft of the Sprint Backlog. The Sprint Backlog details the work to be completed over the course of the Sprint. Days are associated with each task to track where the team members should be on any given day of the project. The Scrum team now knows the scope of work (what user stories are to be implemented) and all of the tasks needed to turn the requirements into an operational product that can be deployed and used. To solidify its deliverable the Scrum Team defines the Sprint Goal. This is the overall objective that will be met by completing the identified scope of work. In this example, the team is expected to deliver a product that allows the “Help Desk Analysts to Add, View & Update Support Tickets”. After evaluating all tasks necessary to complete the requested scope of work, the team commits to completing user stories US1.1 to US1.5 for the first Sprint. But, keep in mind (with Scrum) the Development Team could have asked to have one or more user stories removed from the first Sprint.Ultimately, it's up to the Development Team to convey how much can realistically be accomplished during a Sprint.

Conclusion

Scrum provides a framework that makes it easier for project teams to complete SDLC activities to yield a specific scope of functionality. The Scrum approach is much different from the detailed Rational Unified Process, which leaned more heavily on detailed specifications that took several months to implement. However, it should be noted that some argue that Scrum was not designed for more detailed, complex projects. And, in actuality it may not have all of the artifacts needed to support a complex project that includes interface engines and servers to share messages and data across a widespread region. But, many organizations implementing less complicated business applications stand behind the Scrum approach.

6 Common Blunders That Cause An IT Project To Fail

Working in the Information Technology field for over 17 years has its advantages. Mostly, the knowledge I've gain from being hired to help an IT project recuperate from failure.  As America struggles to get back on its feet, most companies are working hard not to have a failed project. This is because failed IT projects are very costly in that the company spends money; but gets nothing in return. The following paragraphs list the top six reasons I've seen IT projects fail.

#1. Unfounded Requirements Assumptions

Within IT, we all know requirements are defined by the customer (see my blog article titled: Requirements: Understanding the Customer's Vision ). Requirements may come from taking notes during a meeting with the stakeholder and translating the notes into requirements. Alternatively, requirements may also come from making a list of questions that you ask the stakeholder. You then use the stakeholders' response(s) to define one or more requirements. So, what about assumptions? Even if a Business Analyst or Systems Analyst derives assumptions; the assumptions should also be discussed with the stakeholders. What's not a good practice is adding assumptions to a requirements document; and, distributing the document without discussing the assumptions with the stakeholders. Discussing assumptions with the appropriate stakeholder(s) before adding them to the requirements document is essential. This approach develops trust and shows the stakeholders they are in charge.

To avoid confusion or miscommunication, it's best to make sure all requirements are discussed, especially those derived from assumptions, before they are added to the requirements document.

#2. Making Promises Without Understanding What it Would Take to Keep Those Promises

This is one of the most frustrating problems--especially for those who diligently work hard to ensure all projects they support are successful. Those responsible for negotiating timelines with the customer should always talk to the team about proposed timelines before any promises are made. If short timelines are needed, the best approach is to prioritize requirements. This way requirements can be implemented by priority (understanding that all requirements can't be assigned a "High" priority). Negotiating realistic time-frames is key to successfully completing a project. On the other hand, making promises that include short turnaround times for larges amounts of work isn't a good idea. This usually leads to poor quality work that frustrates the customer and makes the entire IT team look and feel bad.

#3. Using a Role Other Than A Business Analyst/Systems Analyst to Gather Requirements
Requirements gathering is about more than just talking and writing. The Business Analyst/Systems Analyst responsible for defining requirements has learned elicitation techniques to define what the customer needs and wants. In addition, the Analyst has learned Gap Analysis techniques, traceability and other requirements-related techniques. Assuming anyone on the team, including Technical Writers or Developers, can define requirements can lead to costly mistakes. The roles in IT are divided such that each team member brings the specialty needed to accurately accomplish specific activities within the Software Development Life Cycle. When a practice other than an industry best practice is used; unwanted, unexpected results will usually surface.

#4. Releasing Software Without Proper Documentation

Before a new system is released, the proper documentation should be created. Most team members hate writing documentation; but that doesn't minimize the fact that system documentation is crucial. Any new business application should be accompanied by the following:

a. End-User materials - User's guides, getting started guides, quick reference guides and other materials needed to tell the user how to install, setup and use the system is important. (See my blog article titled Technical Writing & Technical Training Materials.)

b. Training Materials - Some systems may be complex enough to require user training. For example, Enterprise Resource Planning Systems (ERPs) should never be implemented without a cohesive plan to provide users with training. Training is important because it ensures users understand how to use the system to do their job. (See my blog article titled Technical Writing & Technical Training Materials.)

3. Re-engineered Business Process Document - If a new business application causes an organization's business process to change; it is imperative to educate the users. For example, to order a magazine users may call the support desk. The Customer Service Rep. do the following:

1. Take the order;
2. Type up a label and invoice; and
3. Send the request to the mailroom to fill the order and mail it out.

But, what if the company installs a new system. With the new system, the customer still calls the support desk. However, instead of typing up the invoice and mailing label; the Customer Service Rep. is now expected to enter the information into the system. The system then creates the invoice and sends a notification to the mailroom. Notice how end-user documentation will tell the Customer Service Rep. how to use the system to place the order. But, also notice how the process has drastically changed. Neither end-user nor training materials typically address the business process changes. This is why a plan should be implemented to document the business process change. The documented process change can be made part of the end-user's training. Or, the relevant documents can be given to employees impacted by the change. This ensures the organization continues to run smoothly with little downtime. It also ensures employees understand how to do their jobs with a new system in place. (See my blog article on Business Process Re-Engineering and Enterprise Architecture, Segment Architecture & Solution Architecture ,)

#5. Hiring a Project Manager Who Doesn't Understand the Project Manager's Role

 The Project Manager (PM) is one of the key people on the project. In addition to managing the project budget, timelines and deliverables; the PM is the key interface between the IT team and the customer. It is important that the PM understand the balance between customer responsibilities and the IT team.

I worked on an important project with a PM who negotiated due dates without establishing "how" the work was to get done. The PM wanted the customer to pick the templates and methodology that would be used to complete the work. With due dates already negotiated, I knew the more time it took to get the project started; the less time we had to complete the work. I knew the longer we "sat back and waited on the customer"; the less likely we were to succeed. Instead of sitting around I put together the templates based on the methodology I thought would be best for the customer's environment. Although I was not the PM; I still did not want to be part of a failed project. I pleaded with the PM to take the templates to the customer and ask the customer to simply review and provide input on what we provided. One meeting between the PM and customer gave us the go-ahead we needed to get started. The customer became enthusiastic because the project began to move forward. Things were getting done and the customer knew exactly what we would deliver and the approach we would use to do the work. As problems arose the PM was stumped. But, each time I used my experience to advise the PM on the best way to tackle the problem to achieve maximum project success.

Not everyone on a project team will have the experience I have. But if the team has a Project Manager who understands the various IT roles, SDLC methodologies, the customer's role and most importantly the Project Manager's role and responsibilities--things should go just fine.

#6. Not Using a Cohesive Methodology to Implement Software

It is not uncommon for a non-IT company to believe IT work can be accomplished without a methodology. The one company I stepped into that did not use an IT methodology to complete IT work experienced failure over and over again prior. The non-IT company hired IT people. But, since the non-IT people didn't know what they were doing; they inadvertedly hired IT people who didn't know what they were doing. So, the non-IT company ended up with an IT Department that had extremely weak IT skills.

Consequently, no one in the company trusted the IT Department. When I interviewed to join the IT team; the IT team assured me everyone (besides the IT Department) was responsible for the project failures. I wanted to discuss the methodology being used to do the work. I was told a methodology had not been adopted. So, the first thing I did was point out that it is impossible to successfully complete a project without using an "established" methodology.

I recommended an approach and created and circulated the templates. I documented the approach using a Visio diagram that everyone could follow and understand. Then I suggested that we try the approach out on a small scope of work, which we did. Everything went smoothly and the project was a success. The company adopted the methodology and greed no IT work would be done without using the agreed upon approach.

In short, never try to complete IT work without using an established methodology. These methodology were established after teams attempted to do work without them.

In Summary

Following is a list of things you can do to keep your IT project on the right track and avoid the blunders that cause projects to fail:

#1. Always have unfounded requirements assumptions approved by the stakeholder before they are stated as requirements.

#2. In IT, always understand what it will take to keep a promise before you make the promise.

#3. Always use a Business Analyst/Systems Analyst to gather and manage requirements.

#4. Always make sure proper documentation has been developed before releasing a new software application.

#5. Always hire a Project Manager who understands the Project Management role in its entirety and has experience successfully filling the role.

#6. Always use a cohesive methodology to implement a software application.

Value-Driven Agile User Stories & Test Cases

I’ve had an opportunity to use Agile methodologies while working with a large federal agency and a few other organizations. The large federal agency project was most interesting because it was a complex project. One thing I noticed right away was the level of collaboration used. The experience was very different from what I had been accustomed to. The Development team was large, but despite its size everything was well organized. Problems were discussed daily and solved before the next day’s meeting. It was great to get experience in supporting a large project using Agile. But I still was not convinced user stories were better. This is one key reason it has taken some time for me to actually write about them.

After spending years writing use case specifications and software requirements specification, I wasn’t sure user stories where a good idea. But after working with them over time I began to see their value. I wanted to use this blog article to discuss the format I use to write user stories and present some examples, which I hope are useful.

Value-Driven User Stories

User stories do a good job of presenting requirements in a way that is more concise and easier to understand. Over the past couple of years I have focused primarily on writing value-driven user stories. This means I try to make sure every aspect of the user story adds value in defining the software functionality as it pertains to user expectations. I think facilitating a meeting does mean asking questions to help users think and talk about what they want. But I also think the BA or SA has some editing to do to make sure the content is as useful as possible. For example, I could write a user story that says: "A salesperson wants to add an order to meet customers’ needs." I’ve included the role (salesperson). I’ve also included the what (add an order) and the why (meet customers’ needs). However, the “why” can be written to add the same level of value as the “who” and “what”. If I rewrite the user story, it might look like this: “A salesperson wants to add customer orders to track products purchased”. This user story ties orders directly to products purchased.

In this example, we would expect the user story conversations to include discussions not only on customer orders but also products. This is useful because a customer cannot place an order without a list of products or services to order from. 

From a Developer perspective (i.e., Database Developer or Software Developer) writing user stories that are concise and value-driven strengthens the quality of the requirements and, ultimately, the product being built. The following example includes a user story that associates software problems with trouble tickets. Notice in the Notes section taken from the conversations, “problem description” is discussed. Also notice the user story description provides insight to the workload and the business users’ objective for the user story (i.e., “they want the system to help them process new tickets in a timely manner”, which results in alerts being added).

To make user stories easier for Developers to work with, I embed the use case in the user story. In the following user story [employee] is the role, [submit trouble tickets] is the use case or the “what” and [to describe software problems] is the why. This approach helps developers transition into user stories more easily. They always know to look to the middle of the user story to extract the use case. And, they know the role is at the beginning of the story with the why at the end, as applicable. 

 

The above user story is ready for development. It includes the details necessary to convey the functionality required for the Product Owner and Development Team to all agree on what “Done” means. Notice this user story is assigned 8 story points. To add story points, the Development Team used the Fibonacci sequence (1,2,3,5,8,13,21,34,45), which when diagrammed shows an upward curve indicating an increase in complexity as the numbers go up . They gave this user story 8 story points. This story serves as the baseline to assign points to all future user stories. More complex user stories will consistently have a higher number. User stories with the same complexity will be assigned the same number. And, user stories that are less complex will be assigned a lower number.

Test Cases

Test Cases are a great way to confirm user requirements have been met. The following capture shows the test cases associated with the “As an employee I can submit trouble tickets to describe software problems” user story.

Initial Task List

During the Sprint Planning Meeting, the Development Team can identify all of the tasks associated with development. The System Administrator should also document any items he/she must complete for development to commence and move forward. If a Database Developer and/or Data Analyst is part of the project these individuals should also add items to the list. Once the task list is created individuals can volunteer for the work they want to complete or the work can be assigned by a team lead, whichever is applicable.

The Barriers/Action Items List

As the Development Team works to complete the iteration items for a Sprint, problems always arise. One way to manage daily problems is to keep a Barriers/Action Items list. The list should be accessible to everyone at all times. It can be updated during the daily standup as well as throughout the day. If SharePoint is used to manage the Barriers/Action Items list, the Product Owner, Project Manager and team members can all subscribe to alerts to be notified as new items are added. This way if you can solve a problem, you hear about the problem as soon as it is recorded.

Hopefully you will find this information useful and it will shorten your workdays and make your career a bit more brighter.