4squareviews

I am going over the Agile Practice Guide, a publication put out by the Agile Alliance in conjunction with the Project Management Institute.    I am currently reviewing chapter 5 on the implementation of agile projects, and am now on section 5.3, Troubleshooting Agile Project Challenges.

On pages 58 and 59 of the Agile Practice Guide, there are twenty-one challenges or “pain points” described together with the suggested solution(s) to the problem.   However, they are listed in a random, laundry-list fashion without much rhyme or reason to the order.  So what I have done is reviewed all the suggested solutions and grouped those challenges that require the same type of solution.   These five types of solution are:

1. Production of agile charter
2. Product backlog/user story definition
3. Kanban boards
4. Focus on team roles/responsibilities
5. Testing implementation

This second group of solutions, which centers on the creation of a product roadmap culminating in a project backlog with user stories, covers one third of all the challenges or “pain points” listed by the Agile Practice Guide.

Let’s pull back for a minute and discuss what is involved with a product roadmap.   In an agile project, you start with the product vision, which is how the customer envisions how the product will look and perform.   This vision is of the finished product.   That is like saying you are going on a journey and stating what it at the final destination.   You then have to figure out how you are going to get from here, the starting point, to that final destination.   That is the product roadmap, where you start creating requirements or features that the final product should have.   For each requirement, the team and the product owner should the expectations and value that the requirement represents for the customer.

The result should be a series of user stories which describe how the feature or requirement will fit into the overall final product.   The stories must strive to be as objective as possible, so the acceptance criteria for when the user story is “done” can be easily agreed upon by the customer and the team.

Once the user stories are clarified, and put into the product backlog (the equivalent of the “scope statement” in a traditional project), you can then move on to estimation of how long each story will take.   This takes the laundry list of user stories and ranks or prioritizes them according to their size (how long the completion of the user story will take) and their impact on the overall final product.   Once these factors are weighed, you can then figure out which user stories to work on first–hence the term product roadmap.

Okay, so that’s how the process is supposed to go.   If any of these steps listed above are not done carefully, problems can arise.   The list below shows the challenge or pain point an agile team can experience and its recommended remedy that has to do with the product backlog and the user stories it comprises.

1. Poor user experience–the user needs to be involved in the process of creating the user stories that make up the product backlog
2. Inaccurate estimation–reduce the story size by splitting up the user stories.  Use relative estimation involving the whole team in order to estimate the size of user stories.  Consider spiking (doing a focused study) to understand any story that is unclear.
3. Work delays/cost overruns due to insufficiently refined product backlog items–the product owner and the team should work on user stories together.  Create a definition of “ready” (as in “ready to start work on) for the user stories.  Consider splitting user stories up so that they are smaller.
4. Work is not complete–Work on the definition of done (i.e., acceptance criteria) for user stories and for the project as a whole.
5. Too much complexity–For each user story, encourage the team to focus on the question, “What is the simplest thing that would work?”   This uses the agile principle of simplicity, which can always be described as “the art of maximizing the amount of work NOT done.”
6. Too much rework–measure the work in progress (WIP) at the beginning of the project.  Consider team spikes (doing a focused study) to learn and focus on adding value rather than perfecting the design.    Create a robust definition of done for user stories and shorten iterations if necessary.
7. Inefficiently ordered product backlog items–Rank the user stories not just by their duration, but also by the value that they will contribute to the final product.

You can see that some common theme of these solutions is to make sure that the entire team including the product owner work on the creation of user stories, to reduce the complexity and/or size of the user stories if possible (especially at the beginning of the project), and to create acceptance criteria (i.e., the definition of “done”) for these stories.  If you can make sure to incorporate these practices in the creation of the product backlog and the management of the user stories that it comprises, many of the issues or challenges listed above can be avoided or at minimized.

The next set of solutions deals with the clarification not of the product (which is what the product backlog is for), but of the process, and Kanban boards are an excellent tool for dealing with challenges in this area.   These challenges addressed by Kanban boards will be the subject of the next post.

Filed under: Uncategorized |