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