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.

Before I dive into Part 3 on my series about Agile Process Overhead, I wanted to review where we are and interject a little wisdom around all of this.

You may recall that I had a client come to me with great concern (frustration?) about all the “overhead” in adopting Agile. Specifically, they wanted to address:

• What goes in the Sprint Backlog?
• How do you allocate your time effectively?
• How do you “plan” for unplanned work?

Each of these seemed to cause a lot of overhead for their ScrumMaster and the team. That confused me and so I decided to post some ideas about them. I addressed the first bullet in Part 1 of this series, and the second bullet in Part 2.

So let’s take a break before moving on to Part 3,: “How do you ‘plan’ for unplanned work?” Here is what I want to raise as a guiding mental model: the 5 Orders of Ignorance. This may appear to have nothing to do with the perceived process overhead with Agile. I think it has everything to do with it.

Where do the 5 Orders of Ignorance come from? Phillip G. Armour outlined these in his book The Laws of Software Process. (You can also find a quick outline of them in a 2000 Communications of the ACM Article.)

If we are looking at process overhead, I think applying the 5 Orders of Ignorance is great guidance:

• 0th Order Ignorance: Lack of Ignorance
  • I (probably) know something
• 1st Order Ignorance: Lack of Knowledge
  • I do not know something
• 2nd Order Ignorance: Lack of Awareness
  • I do not know that I do not know something
• 3rd Order Ignorance: Lack of Process
  • I do not know a (suitably effective) way to find out that I don’t know something
• 4th Order Ignorance: Meta-Ignorance
  • I do not know about the 5 Orders of Ignorance

Where do you think the troubled team is in the 5 Orders of Ignorance when they are struggling with Agile Process Overhead in the guise of an overloaded Sprint Backlog, allocating team members, and planning for unplanned work? How do you think Agile and Lean approaches actually directly impact the 5 Orders of Ignorance? And, in so doing, can you see ways that, in attacking the 5 Orders of Ignorance, they directly impact costs to teams and organizations in a variety of domains?

Okay, next post I will complete Part 3 of our Agile Process Overhead series. And we’ll find out how Agile addresses these 5 Orders of Ignorance. Stay tuned!

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.