Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Successful Agile Planning: An Iteration How-To, Part I : Page 2

Agile development practices, when performed correctly, are lightweight and inexpensive, avoid wasted cycles, and ensure that just the right features are built


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


Ken Clyne is an Agile Coach with Rally Software where he pursues his passion for helping teams collaborate effectively to eliminate waste, improve quality and continuously deliver a high value product. Ken has over 20 years of experience spanning the software life cycle. He began his career as a software engineer developing compilers and air traffic control systems. Ken�s focus of the last 12 years has been helping teams adopt lean incremental, iterative approaches. He is a certified PMP and ScrumMaster and has a B.S. in Computer Science from the University of Edinburgh in his homeland of Scotland.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date