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.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.![](http://assets.devx.com/articlefigs/43937figure2.jpg)
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
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.