Agile Living: Estimation
Practice #3: Estimation
In a couple of our Agile Living posts I’ve made reference to “point values” for projects. This is another practice inspired by Agile software development. Before adding a project to the current or upcoming iteration, we assign a point value to it. This is a value between 1 and 3, where 1 is the easiest, and 3 is the hardest.
These numbers have only relative significance. They are not connected to any real-world metric such as “days required to complete”. They are interpreted relative to each other - a 1-point task is easier to a 2-point project, which is easier than a 3-point project. The only relation to a concrete measurement is that they must all be accomplishable within a single three-week iteration.
If it’s not a concrete number measure, how do we judge task difficulty? It’s a gut-feeling call - is this project one of the easier ones we’ve considered, moderate, or one of the hardest we might attempt to accomplish in three weeks? We also explicitly include emotional difficulty in our estimates. One project might require only a single phone call to accomplish, but that phone call might be one that causes us significant anxiety, causing the project to receive a “3″ rating. The goal is to come up with an overall rating of effort, whether from physical effort, financial outlay, length of time required, or emotional resistance.
Planning poker
The actual project estimation is conducted almost like a game - agile software refers to this step as “planning poker”. One of us counts to three, and on three we both hold up a number of fingers equal to our estimate. The point of estimating simultaneously is so that neither of us influences the other beforehand. Remember, this is all about gut feeling. Once we’ve both shown our “hand”, if both estimates are equal, we write the number on the card, circle it, and move on to the next card. If not, we discuss.
Note that we do not try to “split the difference” between the differing estimates. Usually a difference in estimate indicates that we understand the project differently, or that one of us has thought of a complication the other is unaware of. So a difference in estimation is an opportunity to come to a better understanding of the project being estimated. We don’t put a final estimate on the card until we’ve reached a consensus.
Rationale
The primary goal of estimation is achieving predictability. At the end of each iteration, during the retrospective, we record how many points’ worth of effort we scheduled, versus how many we actually accomplished. As we become more adept at estimation, and as we collect more statistics, we will come to a better and better understanding of how much work we can reasonably expect ourselves to accomplish in a given iteration. This, in turn, will help us move forward with our various plans at a steady, sustainable pace - having confidence that we can accomplish what we’ve set out to do.
avdi on February 19th, 2009 | File Under Agile Living | Comments -