Agile Development Blog

Team 100% allocated commits to 8 Items for the Iteration

This is the final post in my series about a client’s consternation with regard to Agile Process Overhead. This last topic had to do with their Sprint Planning Meeting and how to make commitments.

The problem? “Jean, how do we plan for unplanned work?”

In this case, the team was referring to production issues that would come up that HAD to be addressed, even though they could not be predicted during the Sprint/Iteration Planning Meeting.

So, how DO you plan for unplanned work? If you look at my post about the 5 Orders of Ignorance, where would you place this issue? Well, it is the 1st  Order of Ignorance:

• 1st Order Ignorance: Lack of Knowledge
  • I do not know something

For this team, in their planning meeting, they truly can say with conviction, “We know that we don’t know something.” That is, for this team, they know that they can’t know all the production issues that may come up. Fortunately for this team, they don’t fall into the higher orders of ignorance. Most notably, they are not in the clammy grasp of the 3rd Order of Ignorance:

• 3rd Order Ignorance: Lack of Process
  • I do not know a (suitably effective) way to find out that I don’t know something

We have a process! It is called Agile software development! And here is how Agile helps us plan for unplanned work, the things we know that we do not know.

1. Do not commit all of your team capacity to the work you DO know about (i.e. Prioritized Backlog Items)
2. Track Iteration over Iteration the amount of unplanned production work that comes in (e.g. “Last Iteration we didn’t finish 3 of our committed items because we had 5 major production issues come in. The Iteration before that, we had 6 minor production issues come in; we did not complete 1 of our committed items.”)
3. Declare and hold a buffer that is an average percentage of time you have production/unplanned work arrive after Sprint Planning (Iteration = Sprint in Scrum) has completed (e.g. “Based on the last 5 Iterations, we have spent an average of 30% of our time on production issues. Therefore, we must hold back a 30% buffer from our Sprint Planning capacity this timebox.”)
4. During the Sprint/Iteration, continue to track how much unplanned work comes in that impacts the team.
5. Report this unplanned work and its impact in the Sprint Demo and Review meeting. Continue to evaluate its impact on the team’s ability to take on new, value-based, innovative work during the Sprint/Iteration.
6. If NO unplanned work comes in during the Sprint, consult with the Product Owner about the next highest priority items the team could invite into their commitment for the Sprint. (Some teams like to talk about this “back burner” work during the Sprint Planning Meeting. They plan it out with tasks and estimates but do not commit to it.)

Team buffers and only commits to 6 Items for the Iteration

Finally, a team that finds itself continually taking on more and more unplanned work needs to run a Retrospective specifically on this topic.

This is part and parcel of a real Agile culture: retrospect on items that are getting in the way of our ability to deliver value.

Where is all the unplanned work coming from? Do we really not know our priorities? Do we really not stick to our Sprint Plan?

Is our product technical debt so great that we are forever mired down in triaging the product? Is our testing strategy not disciplined enough with regard to how we declare “Done” items? What new agreements or strategies must we put into place to reduce the amount of unplanned work?

Now we have a process for how we deal with work that we cannot plan for. Hold your resolve around this. Do not be pressured into fully filling your Sprint/Iteration until you are able to successfully deliver committed items.

Your Burndown Chart will have a more gentle slope; your Sprint/Iteration backlog will have fewer items. AND, you will be able to absorb that work we know that we don’t know.

About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.