Iteration planning occurs on the first day of the iteration. A guiding tenet is — those who do the work, plan the work — so it is essential that the entire Delivery Team participate in planning. It is a collaborative (not directed) exercise facilitated by the ScrumMaster. The Product Owner is a key participant who will answer the tough questions about the Product Backlog that arise during iteration planning.

At the end of iteration planning the team makes a commitment to deliver the selected items. There is also a reciprocal commitment that (barring emergencies) the Product Owner will not change the scope of the iteration.

The team only plans the work they know they can commit to completing and this determines what they pull from the Product Backlog. The team’s velocity may be enough to help in this decision. However, new teams on their first or early iterations will either not know their velocity or will not have a velocity stable enough to use as a basis for commitment. For these teams we suggest using capacity to make commitments and then evolving when ready to more lightweight techniques.

With the capacity based technique we pull items off the backlog and plan the tasks needed to deliver those items until we have reached the team’s capacity.

First we determine the capacity of the team. Simply multiplying the number of days in the iteration by 8 will not yield a realistic number. We all spend time on unplanned and overhead activities and we need to allow for this. New agile teams are quite often not part of a mature agile organization, so expect conflicting priorities and team members having to split time across multiple teams.

For example Sophie’s team may have a 2-week iteration. 1 of the days may be allocated for iteration planning, the demo and the retrospective. Sophie decides that on any given day she manages 6 hours of interrupted implementation work. Also Sophie still has some handoff work to do for her previous team and that occupies 20% of her time. Sophie’s capacity is therefore 43 hours (9 * 6 * 80%).

Once we determine capacity, planning proceeds as follows:

1. The team pulls the highest priority item off the product backlog
2. The item is discussed in enough detail to identify tasks that need to be performed
3. Team members sign-up to own the tasks
4. Tasks owners estimate the number of ideal hours they will need to implement each task
5. The team checks the cumulative number of task hours against their capacity and decides if they can commit to delivering the product backlog item
6. If so, the team commits to the product backlog item and planning continues with the next highest priority item (step 1)
7. Once the team has reached full capacity, the team commits to the iteration and planning is complete

It is a fundamental of a self-organizing team that tasks are not assigned. However tempting it may be for the ScrumMaster they should not steer this process. Tasks are estimated in ideal hours — the amount of time to complete a task with no distractions or waiting.

Tracking the Iteration

During the iteration we perform all the tasks necessary to deliver the product backlog items we committed to and every day we hold a daily standup. A simple meeting where we answer three basic questions:

* What did you work on yesterday?
* What are you working on today?
* Do you have any impediments?

We track progress during the iteration using an iteration burndown chart. The X-axis represents days in the iteration and the Y-axis represents the number of task hours remaining (left side) and number of story points accepted (right side).

An iteration burndown is updated daily by the team. From this burndown chart we can see that the team is on schedule (the blue bars are below the ideal burndown line).

Conversely we see that this chart represents a team that struggled from the very start of the iteration and completed less than 50% of their planned work and had only a few of their stories (or defects) accepted by their Product Owner.

It is important that the team, not the ScrumMaster, update the hours remaining. There are many benefits to being a member of a self-organizing, self-managing team, but with those benefits also comes responsibility and accountability.

Closing Out the Iteration

At the end of the iteration we demonstrate our product increment to the product owner and other stakeholders. Everyone’s invited, we prep minimally and we keep ceremonies to a minimum (no slides or documents).

Inspection and adaption is the keystone of a continuously evolving and improving team.

After the iteration review the team has a retrospective to determine:

* What did we do well?
* What didn’t we do well?
* What do we need to change to do better?

Other Planning Approaches

Once a team has a velocity that is stable they may choose to make iteration commitments based on velocity. Tasks are still identified and estimated as this provides the needed granularity for tracking the progress of the iteration and provides context for the daily stand-up meeting. A benefit with moving to this approach is that lower priority tasks can be left unassigned until ready to be worked which helps reduce the work in progress and provide better throughput.

If stories are small enough and/or task identification becomes rote, tasks may become unnecessary overhead and the team may consider omitting them.

Some teams take this a step further and reduce estimation to its simplest form by making all stories the same size. Breaking stories down is typically a big challenge for teams new to agile so this approach is best attempted by a mature team.

Planning Shortens the Feedback Loop

The mechanics of our agile iterations provide us a quick feedback loop where we can regularly inspect and adapt. The capacity based planning technique I explain here further shortens the feedback loop allowing teams to realize before starting work whether the iteration is at risk or not.

Earlier this year I was working with a team in Chicago and on the morning of the iteration planning there was no energy in the room. I asked the team what was wrong. They told me their plan wouldn’t make any difference they were going to have to do it all in 2 weeks regardless. The team started planning, pulling items off the product backlog and creating their iteration backlog. When the team had committed about half of what the Product Owner had originally hoped for they had reached their full capacity. I brought the Product Owner into the discussion; he looked at the Iteration Backlog then left the room. He came back shortly thereafter to announce that he’d just spoken with the customer and they had agreed to push back the release date to allow for an extra iteration. The team was delighted.

If you are a beginning agile team consider starting with capacity based planning to shorten your feedback loop. Once you have established a consistent rhythm of successful delivery then it may be time to think about optimizing. You’ll know when that time is. As a self-organizing, self-managing team your reflection on your retrospective data will point the way.

Bibliography

Cohn, Mike. Agile Estimating and Planning. Boulder: Prentice Hall, 2006.
Roth, Ronica. “It Takes a Village: 6 Ways To Fill the Product Owner Role.” Better Software. September 2009. www.stickyminds.com.
Sorowiecki, James. The Wisdom of Crowds. New York: Anchor Books, 2005.
Tabaka, Jean. Collaboration Explained: Facilitation Skills for Software Project Leaders. Boulder: Addison Wesley, 2006.