Relative estimation
…one or more development teams working on collaborative product discovery.
✣ ✣ ✣
{{{wish full}}}
The idea of relative estimating being better than absolute is not merely a premise. It has been shown by Lederer and Prasad in “A Causal Model for Software Cost Estimating Error” (1998) and Vicinanza et al. in “Software Effort Estimation: An Exploratory Study of Expert Performance” (1991).
Velocity is “the great equalizer”, according to Mike Cohn, because it is what lets a team be able to successfully plan a project as long as their estimates are consistent (even if there is systematic error in those estimates). Being consistent is much easier to achieve and this allows teams to create plans.
Therefore:
{{{therefore full}}}
✣ ✣ ✣
✣ ✣ ✣
To process
- A story that would have been estimated as 6 two sprints ago should still be estimated as 6 today.
- You build your reference as you go.
- Use planning poker for consistent team estimation.
- Fibonacci numbers: something is a 3, another thing is more, but is it less than twice as much (then it is a 5) or is it more than twice as much (then it is an 8).
Sources