Relative estimation is a common tool among various forms of Agile, providing a relative value to the resource requirements of an initiative.  This can be very useful for resource allocations.

Relative Estimation is used to make future predictions based on past experience, knowledge, complexity, size, and uncertainty required to complete backlog items.

Agile Extension to the BABOK^®  Guide – section 7.13

When used in the Strategy Horizon, Relative Estimation is where we talk about how to estimate effort involved in delivering the solution, not the increment. However, this technique is used on all horizons, and it based on experience, knowledge, complexity, size and uncertainty.

Elements

There are several ways to perform estimation. But it comes down to a combination of order of magnitude, resources and time, and team-based estimations. Depending on the horizon, these elements may be utilized differently for a basis of the estimation. 

Approaches

There are different approaches to performing Relative Estimation. Two of them are discussed in the Extension®, but there are others.

First, there is Planning Poker – The team chooses a number from a deck of Planning Poker cards, with any discrepancy being discussed and resolved among the team during the planning workshop.

Another method is Silent Sizing.  The stories are lined up from Low to High based on effort. After they are lined up, they are grouped together for those of similar size.  And each group is given a story point value for each story (not all stories).

Description

Relative Estimation occurs in some capacity across all horizons, at a frequency that is appropriate for that horizon. It guides decision making and prioritization because it determines the effort involved.

The Relative Estimation technique is under the Requirements Management context because it determines an aspect of how Requirements are selected for work. This is not Product Management or Refinement because Relative Estimation does NOT change the requirement itself, only it’s perceived effort and prioritization.

Several additional examples include Delphi, 3 point, PERT, Expert Judgement, Parametric Model, Top Down, Bottom Up. 

Usage Considerations

This is simple to do. As more estimates are performed with a team on a project, the estimates get better and better. Because it is collaborative, the team will learn how to build consensus.

However, if there is a major shift in the skills required, the estimates may not be as accurate. Also, personnel changes can affect the quality of the estimates.

And it really is not a fair comparison to look at one teams estimates to another. There’s just too many factors that make that problematic.

Finally, avoid translating effort for value. Keep the stakeholders focused on value, not effort.

• Agile
• BA Techniques
• Delivery Horizon
• Strategy Horizon