Agile development practices, when performed correctly, are lightweight and inexpensive, avoid wasted cycles, and ensure that just the right features are built. In this article you will find successful ways to make and meet iteration commitments, techniques for leading a team or teams through an effective iteration planning meeting, and tips on how to establish priorities, size your stories, and plan your iterations better.

I am very fortunate as an Agile Coach with Rally to constantly be around teams who want to become leaner and more agile. Those who do the work, plan the work is a principle I hold dear, yet it is a struggle for many to create such a self-organizing, self-managing team. I was reminded of this in July of this year (2009). I was invited to give a webinar on Agile Planning. I expected perhaps a few dozen attendees yet 1400 people registered and 3 months later I was still answering questions. The content of that webinar is the inspiration for this article and my target audience is the team that is new to agile and lean concepts.

The Mechanics of an Agile Iteration

Most of today’s agile teams use iterations to maintain a constant tempo. The iteration begins when the team selects the product features to be delivered at the end of the iteration, identifies the tasks needed to complete those features and commits to the iteration. During the iteration the delivery team meets each day to plan that day. At the end of the iteration the team produces a potentially shippable product increment.

The Product Backlog is the list of desired product features. It is expressed so that each item is value focused. It is owned and prioritized by the Product Owner. The Product Owner represents (or is) the user/client. They act as one voice even if they are not one person (Roth 2009).

Most agile organizations use User Stories to describe their Product Backlog items. Stories should be described briefly with detail deferred until closer to the time that commitments need to be made. Deferring commitment is a lean principle that helps us avoid the waste of detailing stories that may never be implemented and also allows us to make decisions with the maximum amount of information possible.

The list of tasks to be completed in the iteration is the Iteration Backlog. These tasks are performed by a Delivery Team consisting of 5-9 individuals who commit to the work they select for iteration.

The ScrumMaster facilitates the team and the team’s relationships with outside interests. They enforce agile values and practices and don’t make decisions for the team or time and budget commitments on the team’s behalf.

Grooming the Backlog

Before a team plans the iteration the Product Backlog needs to be groomed to ensure that the backlog items are ready to be worked on. This is a collaborative effort involving the Product Owner and the Delivery Team. The Product Owner determines what the priorities are and ensures that everyone understands criteria for acceptance of the backlog items. The team needs to estimate the size of the backlog items and those that are high priority and too large to be completed in an iteration need to be broken down.

Acceptance Criteria

User Stories by definition consist of a brief description. This is not enough information to estimate the story, implement the story and to verify whether the implementation meets expectations. Therefore before the team starts planning we need to ensure we have clear and verifiable acceptance criteria for each story. There are various forms for documenting acceptance criteria. A simple form is just a bulleted list. Identifying acceptance criteria can often reveal new stories that may affect priorities for the upcoming iteration.

Prioritizing the Backlog

The Product Owner prioritizes the Product Backlog. A stack ranking is preferred where no two items have the same priority. This can be a challenge where there are multiple Product Owners but a simple technique such as dot-voting (Tabaka 2006) can help. Where the Product Owner is representing a large constituency more thorough techniques such as Kano Analysis and Relative Weighting can be employed (Cohn 2006). Often size estimates affect how a Product Owner feels about priorities so it is expected that priorities will be revisited after estimation.Estimating is a key component of the self-organizing, self-managing agile team. If we can build a reliable estimation capability we can couple that with empirical knowledge of the team’s velocity to set expectations and make commitments.

Traditionally in product and system development we are not good at estimating our time to complete work. It turns out though that we are very good at comparing things. Try breaking a chocolate bar in two and asking a child which is the larger piece and you’ll see what I mean. Agile teams build on this ability and estimate the size of work by comparing backlog items with each other.

For example, lets say you have some piles of logs to be split before winter. You’ve never split logs before so you have no idea how long it will take but you decide to dedicate 2 hrs a day Saturdays and Sundays. Before you start you decide to estimate the size of the piles so you can monitor your progress.

You could count the logs in each pile but that’s a lot of work and it would take away from your splitting time. Instead you decide to make a rough estimate. There is one small pile. A second pile is roughly twice the size and the last pile has maybe three times as many logs. You assign the numbers 1, 2 and 3 to the log piles to indicate relative size. After one weekend you get the smallest pile done and you estimate you have about 5 weekends worth of work left to do.

Agile teams use a similar relative estimation technique. Just as we assigned unit-less numbers 1, 2 and 3 to our log piles to indicate the relative size, agile teams assign story points to the backlog items they estimate. Teams will often use the modified Fibonacci sequence (1, 2, 3, 5, 8, 13) as a good sequence of numbers to use for estimation.

Of course software is not as tangible as logs or chocolate bars however, we do have a lot of built-in expert knowledge that even we are not consciously aware of (Sorowiecki 2005) and using an estimating technique such as Planning Poker (Cohn 2006) can be very powerful for collecting that knowledge and bringing a diversity of experience and intellect to bear in producing estimates that the whole team can buy-in to.

Relative estimation is quicker than absolute estimation. Whenever days and hours enter the discussion the dialog quickly gets down to the minutiae and there is the added pressure (real or otherwise) to get it right. Also with relative estimation, our estimates don’t decay. We may speed up and get better at splitting logs but that second pile is always going to take twice as long as the first.

Velocity

After a few iterations agile teams will establish a rhythm where the number of story points completed per iteration stabilizes and becomes predictable. This measure is called the team’s velocity. Velocity can be very valuable for setting expectations and planning releases and iterations. In the example shown here the team should plan on between 8-10 story points per iteration.

Definition of Done

Before iteration planning there needs to be a clear understanding between the team and the Product Owner of what “done” means for the iteration. The gold standard is to deliver a potentially shippable product increment but, for most teams, the Definition of Done defines the very best thing that the team can do each iteration. The gap between what the team produces each iteration and what it takes to actually ship is technical debt, work we need to do before we ship and this work needs to go back on the backlog to be scheduled by the Product Owner. The Definition of Done should be revisited and updated each iteration as the definition will likely change as we gain new skills, knowledge and technology.

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.