Agile Estimation
Estimation in Agile tends to land in two camps:
- those that want to estimate work items as a means to roughly predict what is going to happen during a Sprint whilst Sprint Planning for example
- those that focus instead on the exhibited flow by measuring the Cycle Time at periodic intervals of how many uniform sized work items are completed when implementing the Kanban Framework for example.
This article addresses the former situation when a forward predictive estimate is needed.
Velocity
This approach of using abstract units of measure for estimates often causes quite a bit of confusion especially if teams are conditioned to use time based estimates, and so here is a simple example of how to use abstract measures with time-boxes:
Consider a situation where we have a number of equal sized rocks and need to transport them from station A to station B. A traditional estimation approach would involve guessing how long it would take to move all of the rocks to station B. An agile approach by comparison will involve obtaining a few samples first and then obtaining an average velocity.
- Set the timer for 30s and see how many rocks we can move in that time from station A to station B
- In our example we manage to move 1 rock in 30 seconds
- Repeat the same step again, setting the timer to 30s and see how many rocks we can move in the time-box
- In our example we manage to move 2 rocks this time in 30 seconds
- Now we can take an average of the two time-boxes
- In our example this is 3 rocks / 2 time-boxes = 1.5 rocks per time-box (or a velocity of 1.5)
- All we have to do now is total up the number of rocks to be moved
- In our example there are 15 rocks to be moved
- Divide the total number of rocks by the velocity now gives us the number of time-boxes, Sprints or iterations it will take to move all of the rocks
- In our example 15 rocks / 1.5 velocity = 10 time-boxes or sprints that are 30 seconds long = 300 seconds = 5 minutes
- As we do more sprints or iterations the accuracy of our average velocity improves helping us to understand how long it will take to move all of the rocks
Relative Sizing
In the example we considered all rocks to be of an equal size, but we can also use different sized rocks relative to each other. That is, when looking at the rocks we may see that one rock is twice as large as another rock, which also implies that there is twice as much effort to move it from station A to station B.
If we repeat the process and look at another rock we might see that it is twice as large as the first rock and so four times bigger than the smallest rock, implying four times the effort needed.
This is relative sizing and is done by comparing items of work with each other and making judgements based upon how much effort is involved relative to each other.
Story Points
Story Points are a measure of complexity or effort needed to complete User Stories to a potentially shippable, or done, done, done state. They are abstract, in that, they do not relate to time but instead are a magnitude of effort needed to complete a work item in very much the same way as we considered rocks in the example above.
Story Points as a Unit of Measure
When using Story Points with User Stories for example, metrics such as the Velocity show the total number of Story Points on completed User Stories for a Sprint, or more plainly, how much work was done in a fixed time period.
Story Points then become an indication of how much work is attributed to a work item, or User Story.
Exponential Scales
The general premise is that the larger something is, the more unknowns are attributable to it and so an exponential scale is used to reflect the number of unknowns associated with an estimate or Story Point number.
There are several popular exponential scales and include:
- Planning Poker Series® - 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞
- Fibonacci Series - 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89...
- 2 Power Series - 0, 1, 2, 4, 8, 16, 32, 64, 128, 256, ...
Estimation Techniques
- Planning Poker is a basic technique that allows a team to provide a detailed estimate based upon a holistic approach to complete a work item. This technique can be a little slow when compared to others.
- Affinity Estimation is a simple technique that allows a quick rough estimate to be provided, and is useful is a large number of items are needed to be estimated quickly such as when initially creating a Product Backlog for example.
See Also
- T-Shirt Sizing
- Agile Metrics
- User Stories
- Scrum Framework
- Sprint Planning & Product Backlog Refinement
- Cycle Time
- Kanban Framework