Relative estimation is a concept that simply means “comparing two things to each other.” If you’ve ever said something like, “Hey, this tree is twice as tall as that tree,” you already know how to do it.
Agile Estimation
Agile estimation is intended to capture:
- The amount of work.
- The difficulty of the work.
- The risk inherent in the work.
When paired with relative estimation, it results in questions like, “Is this feature as complicated as the other feature we built last week?” Or, “If we take on this feature, is it riskier than the other feature?”.
When work items are similar enough across these questions, we give them the same number on a scale (see table below) that the team has previously selected. As work items differ, the team discusses those differences to understand just how different the work is, relatively, and gives a corresponding number on that same scale.
Amongst these, the most popular is the Modified Fibonacci scale.
Its popularity is for a good reason:
The nonlinear sequence (of the Fibonacci numbers) works well because the gaps reflect the greater levels of uncertainty associated with estimates for bigger, more unknown pieces of work.
Agile teams call these unitless measures of story size “story points,” or simply “points.” It is recommended that teams avoid the temptation to continue to estimate in hours, even when deliberately using relative scales because the perception by stakeholders is often a higher degree of certainty than there truly is.
At one point, “ideal hours” were offered as an alternative to story points. An “ideal hour” is a mythical hour where you can work, uninterrupted, with all the knowledge and resources at your fingertips to get the job done. In practice, this causes too much confusion among the team and stakeholders—someone inevitably confuses an ideal hour estimate with an actual hour from reality.
Estimation must be a Team event
A generally accepted practice is to have the team make estimates together. This practice allows the team to discover how well work is understood, encourages knowledge sharing, builds team cohesiveness, and fosters buy-in. One of the most popular techniques for having these team conversations to obtain estimates is Planning Poker [Cohn 2016]. The gist of it is that the team talks about its work in a structured (but fun) way. The team estimates together, they drive conversation, and they expose uncertainty. And numbers pop out that are just good enough to move forward.