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.

In this post, I’d like to comment on a request from a Rally client I recently visited. Their tool request? A burndown chart for each individual. We were in a small meeting and my intent had been to help them with their Agile adoption. “No, Jean, it is your Rally tool that is the problem.” Hmmmm. Let’s take a look. What seems to be the problem?  “Your tool is not helping our ScrumMaster and management team track individual team members’ burndown during the Sprint. We absolutely have to have that.” Huh?  I had to call foul and get the group to step back and talk about “What’s in a burndown chart and why?”

Individual team member tracking in a burndown chart is a bad smell. It suggests that the commitment made in the Sprint Planning meeting is not a team commitment. It also suggests that the management is not tracking value delivery, but rather team work. I dug further with this group about that. Each individual at this organization was expected to commit exactly to the number of hours any of their tasks would take, and stick to it. That commitment was meant to never change. If a team member was “taking too long” (which they claimed could only be known via individual burndown charts), management would then be able to “do something” about it. What happened to the Daily Standup for team check-in? But I digress.

Tracking in a burndown chart is meant to trace team commitment around the valued items it intends to deliver. At the end of the Sprint Planning meeting, it reflects the team’s initial estimate of effort to achieve that value delivery. During the Sprint,  the burndown chart reflects daily, “Are we going to meet our commitment to delivering this value? If not, what is the single most important, the highest priority thing we must do today?” Finally, the burndown chart  informs the Sprint Demo and Review about what happened with the team’s commitments to value delivery  versus what they were able to complete.

What’s in a name? Well, when it is a burndown chart, there are three things:

1. charting the initial Sprint Planning meeting team-wide commitment to the valued items the team can deliver in a timebox
2. prompting the daily inspection of what is the most important thing the team must do today to meet that commitment
3. informing the the team at Sprint review to evaluate how the team’s estimates and commitment compared to what value the team was able to deliver

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.