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 my post “What’s with all the Agile Process Overhead? Part 1″, I reviewed the contents of the Sprint  Backlog. Hold, commit to, and track items of value there. Nothing else.

I eluded to two other perceived Agile Process overheads, one of which I’d like to peek at today: how do you allocate your time effectively?

This came about from the same client discussion that prompted the post on the Sprint Backlog. In conversation, I discovered that the team believed that they had to be 100% allocated for the entire duration of their Sprint. Hence, the lengthy, detailed nature of their Sprint Backlog. Time to back up.

Team Members determine their ideal effort availability

We’ve already covered one problem with this allocation paradigm: you are tracking the wrong thing in your Sprint Backlog if it is not showing value-add work completion. Now, here is the second villain. No-one can accurately account for all hours of every working day as “ideal effort hours”; that is, hours of completely uninterrupted, undistracted work. Ravi Jha stole some of my thunder on this with his great comment to my previous post. Heed his advice from February 27!

Teams preparing to plan their commitment for a Sprint/Iteration look at their capacity; that is, how much work do we believe we can take on and complete by the end of the Sprint? As Ravi pointed out, a good team assumes from the start that it cannot devote a full 8-hours a day strictly to product backlog value-add work. A good beginning capacity number is 6.  Why 6? Because it is not 8. Until informed otherwise, of our 8-hour work day, we believe each of us can truly be heads-down concentrating for 6 of those hours. The rest of the time will be swallowed up by interruptions, emails, unplanned meetings, and other distractions.

Now, here is the sticky part. As I mentioned in Part 1 of this series, Agile teams must also take into account slack for what they can’t know. This is different than the 6 hour number of ideal effort hours. When we make a commitment in a Sprint Planning meeting, the commitment is:

• We are committing to moving forward with what we currently know so that we can continue to learn by building a potentially shippable increment of the product.
• Our intention is to complete all of these Sprint Backlog items based on the analysis and conversation that has happened to this point.
• We think it will take these many ideal effort hours and we believe we have this many hours available.
• Everyday, we will honestly evaluate how we are doing with our commitment so that we can improve on meeting this commitment AND improve on how we make commitments in the future.

Therefore, a team, not knowing what it doesn’t know, applies a certain additional level of slack or buffer to how it commits. Call this the “Commitment – Buffer of Unknownables” (or C-BOUs). Now the team that has 6 uninterrupted hours per team member per day may additionally say, “Our C-BOU is about 1 hour person right now per day because we just don’t know this product or this process very well. We don’t know what we don’t know, though we know we want to get better.” As the team evaluates the Product Backlog Items with the Product Owner, and as they determine tasks and estimates for this work, they are keeping in mind:

• what ideal hours they will need
• what ideal hours do they have
• how much C-BOU should they hold back

By the end of the Sprint Planning meeting, a commitment then truly represents:

• Items of value we intend to deliver
• Commitment by the team to learn about commitment
• Intention to use the buffer for what they couldn’t have known
• Agreement to evaluate the C-BOU at each retrospective to see if it needs to be bigger or smaller

Some teams call for a bigger C-BOU due to the volatility of their environment. (Okay, they prefer to say their business is very “organic”.) Tracking this capacity buffer is a great way to enable getting to the root of that “organic” nature. Without paying explicit attention to the truth of unknowns and the amount of time they take, a team and the agile project management can create waste and overhead. Teams go into a frenzy mode to meet a commitment that allowed for no buffer, no unknowns. Management applies pressure to meet the commitment despite the clear and present issues that are eating up the efforrt. None of these tactics improve team commitment; they create overhead, waste, and low morale. And they add the cost of manaing all three of these.

That’s it for Part 2. In Part 3, I’ll talk about how you plan for unplanned work, without using a crystal ball :- )

Yesterday, I mentioned a Rally client team I visited that was concerned about the Rally tool’s inability to create individual team member burndown charts.  We swam through that torrent of misperception only to enter a shark-infested tank around all of the overhead involved in adopting Scrum. Wait! Isn’t Agile supposed to cut costs, not add them? Big overhead sounds like cost and waste to me. Where is this overhead? We quickly zeroed in on their overhead: the Sprint Backlog. Specifically, what should be tracked in the Sprint Backlog?

To start the conversation, they told me that they are always 100% allocated. Huh? “What do you mean you assume 100% allocation?” They helped me understand that, in the Sprint Backlog, they assumed that they worked 8 dedicated hours everyday. For them, Sprint Backlog should reflect all of that time.

This was followed up with, “So how do we plan for work that we didn’t know would come up, like production issues?“  Clearly, they hadn’t read Slack by Tom DeMarco or heard of the Theory of Constraints and The Goal by Eliyahu Goldratt and the notion of buffer. So, we had a few things to clarify around this “process overhead”:

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

In this first post on the Sprint Backlog and using Agile to cut costs, I’ll concentrate on the first bullet:

What goes into the Sprint Backlog?

The Sprint Backlog emerges from the Sprint Planning meeting as the team:

• Identifies the highest priority value items
• Breaks them into tasks
• Determines the effort necessary to complete the value items
• Commits as a team

We cut costs by only committing to and tracking the highest priority items that deliver value in that timebox.

We cut overhead by not tracking items in the Backlog that do not contribute to the potentially shippable product increment.

So back to our overprocessed team. We opened up the Rally tool and moved to their Iteration Backlog view. I saw over 50 items, at least. And then, I understood.

The team was putting EVERY task they do throughout the timebox into the Sprint Backlog, whether it added value to the product increment or not.

Imagine having to track all of your day’s activities. Imagine having to, 2-4 weeks in advance, absolutely commit to these full days’ worth of activities. So, indeed, here was the overhead. Vacation days were in the Sprint Backlog: they had 8 hours of effort. Holidays were in the Sprint Backlog: again 8 hours of effort. The book club had to be tracked separately for each individual who attended it.

The result was that the overall team’s Sprint Backlog would show effort being completed, backlog items being marked “Completed”, the burndown chart burning down nicely, and yet no work of product value was started or in progress. This was not a tool issue; this was an Agile adoption issue.

What is the lesson in all of this?

Be careful about what you choose to track in your Sprint Backlog.

Ensure that what you commit to in that Backlog reflects the delivery of product value.

Abiding by this simple guideline will not only dramatically reduce process overhead, but it will also ensure that what we DO choose to track, whether through a taskboard or an automated tool, is work that is intended to produce product value by the end of the timebox.

Now about their allocation percentages and how it contributes to overhead. That is fodder for another post.

Further Reading:

• Part 2: How Do You Allocate Your Time Effectively?
• Part 3: How Do you Plan for Unplanned Work?