RallyDev.com
Fri 6 Mar 2009
How Do You Plan for Unplanned Work? — Part 3
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.
- Do not commit all of your team capacity to the work you DO know about (i.e. Prioritized Backlog Items)
- 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.”)
- 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.”)
- During the Sprint/Iteration, continue to track how much unplanned work comes in that impacts the team.
- 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.
- 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.
Great post Jean! For those new to Agile, this is always a hard lesson to learn and this post outlines great guidelines. Early on in our adoption of Agile this was a constant problem, and it was not very visible. We implemented #s2, 3 & 5 – tracking unplanned work withing the sprint and measuring for patterns sprint over sprint in order to provide burning visibility into what was going on. What do you know, just after a couple sprints, we were able to determine patterns that allowed us to make adjustments to our capacity so this unplanned work did not hurt the overall commitment. In addition, we were able to build into our team practices working agreements for how we as a team would deal with unplanned work.
Brendan, Thank you for emphasizing this need to create burning visibility “sprint over sprint” in order to recognize patterns or trends. These patterns inform us more about the unplanned work and how we tend to treat it (and ourselves!) I also like that your teams explicitly add information about unplanned work into their working agreements. Alistair Cockburn has a team agreement pattern called “Sacrificing the One” where team members take turns carrying the burden of work or a task that no-one particularly cares for. This might be a place where a team could institute a practice of “Sacrifice the One”. Thanks!
(1) If the business side or executives bring over unexpected work, and add x hours of work that needs doing “right now” then they have to help decide which x hours of work to take off (defer). By doing this they usually say, “oh, those projects they are coding are higher priority than this”. Rarely, they say, this new project is higher priority, the hours are swapped out, and everybody stays fully allocated.
(2) Perhaps your way of breaking down projects into pieces is entirely different than ours, but for us each piece is a different size so we may commit to anywhere from 10 to 20 assignments in our 2-week iteration for programmers and with 2.3 programmers per QA member, that makes double that for the QA role, so occasionally a programmer or analyst may help QA.
How can you have a set number of assignments? We vary because each person estimates how long each assignment will take them than fills up their commitment/allocation. The hours per iteration that we allocate is not 80 hours for programmers and QA, but rather 70 hours for programmers and 65 hours for QA because we answer a lot of questions for another department as well as do our work. We put in meetings and presentation/demo preparation time as part of those 65 or 70 hours to be fully allocated. That is, our issue tracking system handles bugs/defects, stories/enhancements, and tasks and each gets estimates of how long it will take the analyst, programmer, code reviewer, and QA.
(3) The downside of (2) is that if you estimate your hours incorrectly you have to talk to your manager and get an extension, which may result in a re-assignment of projects among the programmers, or you just have to work overtime. Because of this, over time we all became very accurate at estimating how long something would take us.
(4) The benefit of such estimating is that if it will take one programmer 8 hours and another 6 hours, you may want to have the programmer that will take less time get the project. This way more gets done and programmers work in their areas of expertise.
Richard, thank you for your post. I see some differences between how we view unplanned work. For me, this is not about the Product Owner ADDING features to the Sprint Backlog. Rather, it is about teams that KNOW that production issues will have to be dealt with during their Sprint because it happens almost every Sprint. They just can’t plan exactly for it. It is work they know they can’t know a lot about. SO, what I have suggested is that teams DON’T allocate all of their capacity to KNOWN work. This is the buffer the team holds back so that, as they make their commitment, they don’t overcommit AND can still be responsive for the production issues that come up. Does that help?
Here is a second concern you might want to address: never allocate everyone’s hours completely. This is not just because of questions that they need to ask. It is because they can’t know exactly what complexities they may run into with the work they are signing up for. So, imagine that someone takes on an assignment that they estimate will take 10 hours. Then 5 more tasks that will take 5 hours each. That is now 10 + 25 total hours they of effort they are committing to in order to complete the work. To make sure that they have slack to take up any complexity or inaccuracy in their estimates, be careful about where you go from here. If the most truly productive hours anyone can have per day is 6 hours (a fairly standard number), look at what their total available hours for two weeks is: 6 * 10 = 60. If you allow slack for what they may not know about the work, say an additional hour per day, that is now 50 hours of work they can commit to. In this example, the team member has committed to 35 hours of work. Until they can prove that they are very good at calculating complexity and estimating the work to complete it, they should not take on more than 15 additional estimated hours of effort.
Once teams learn more about how accurate they are with their estimates, and how many interruptions they have during the day, this slack number can go done or go up. The main intent is to only use a capacity number that helps guide to a commitment they can truly meet.
Finally, this should address you issue in item (3). There is no such thing as extensions in Agile. A timebox is never extended. Either work got done in the timebox or it didn’t. At the end of the timebox we evaluate the reasons it didn’t get done: it was more complex than we thought, the developer didn’t have the appropriate skill set, the tester wasn’t available, both developer and tester were pulled into an emergency. The timebox doesn’t change ever. What changes is what we commit to in the next timebox. Given that work wasn’t completed, what should we do in this next timebox.
Does this help?