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.
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.