Relative estimation

…one or more development teams working on collaborative product discovery.

✣  ✣  ✣

Consistent estimation of effort makes planning a breeze.

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:

Always estimate relative. Establish a common base for estimation across teams to allow for planning on a larger scale.

✣  ✣  ✣

✣  ✣  ✣

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

• Mountain Goat Software » Mike Cohn » Establishing a Common Baseline for Story Points
• InfoQ » David Morris » Estimating on agile projects: what’s the story, what’s the point?
• Alex Yakyma » Why Progressive Estimation Scale Is So Efficient For Teams
• InfoQ » Ben Linders » Agile Estimation for Release Planning

---