Skip to content
Browse
BABOK Guide
BABOK Guide

7. Techniques

7.13 Relative Estimation

Agile Extension to the BABOK® Guide

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

Estimation is discussed at length in the BABOK® Guide: 10.19 Estimation. The Agile Extension to the BABOK® Guide builds on the information in the BABOK® Guide and describes relative estimation techniques that can be applied in an agile context.

In an agile context, estimating is progressive and occurs in alignment with iterations. Initial estimates are not expected to be as accurate as latter estimates provided closer to delivery. The ability to accurately estimate improves over time as new information is discovered about both capacity and capabilities. The continuous feedback and learning that is central to agile business analysis provides clarity and understanding regarding the components, characteristics, and complexity of the work.

Estimates are not part of the solution and are used to guide internal decision making. Estimates provide value to stakeholders by

  • determining cost and effort,

  • establishing the priorities of the initiative, and

  • committing to a schedule.

In addition to the basic approach of estimating based on historical knowledge, agile business analysis practitioners frequently apply a relative estimating model in which teams develop stories that define user needs and benefits. These stories are analyzed and numeric values are applied to each story as story points. Story points apply a Fibonacci scale to abstract measurement of factors indicative of story size. Relative estimation is based on the team's past experience and will vary between teams.

A story point is a relative number assigned to each story that defines the estimated effort a team will have to apply to deliver the story. Story points are usually based on what the team knows about the story in five key areas:

  • Knowledge: How much information does the team have?

  • Experience: has the team done this/similar item before?

  • Complexity: How difficult is the implementation likely to be?

  • Size: How big is the story? How long will it take?

  • Uncertainty: What variables and unknown factors might impact the story?

The total number of story points delivered within any given iteration is considered to be the team's velocity, or how much a team accomplished within the iteration. Over several iterations, teams will have a better understanding of their actual velocity. This allows them to make better informed estimates and commitments in subsequent iterations.

There are several ways to estimate story points. Business analysis practitioners begin with

  • an order of magnitude,

  • a given set of resources and a fixed iteration, or

  • a team based estimation of the time required for a sample of stories of different sizes, and then extrapolate from there to estimate the work that can likely be done in an iteration.

.1 Planning Poker

Planning poker is a technique to estimate story points for a team. During the Planning Workshop, the team reviews each backlog item or story. Once the team has a shared understanding of the story, each team member chooses a number based on the story point scale. Where alignment is within one degree of numbers, the team chooses one and moves on. Where there is a wide variation in numbers, the team discusses the discrepancy to uncover any assumed knowledge. The goal is for the team to reach agreement for each story point during the Planning Workshop.

.2 Silent Sizing

Silent sizing is an approach which engages the entire team in estimation activities. To do this, the team needs backlog items prepared on individual cards and a wall, table, or similar space to line up the items. Taking turns, a team member selects a card and places it along the wall. The team members repeat this for all cards, creating a linear line with the smallest cards on one end and the largest cards on the other end. The team then identifies breaking points to group similar sized items. At this point, the team assigns a number, such as the Fibonacci scale, to each grouping. Each card is assigned the size of its group.

.1 Strengths

  • A simple, reliable methodology that fits well with agile practices. It is highly adaptive and is likely to become increasingly accurate throughout successive iterations.

  • The sizing approaches are highly collaborative and based on consensus, and will likely have a positive impact on development teams.

 

.2 Limitations

  • Relative estimates are based on historical data, and accuracy is dependent upon the similarity of new stories to stories previously delivered. If new stories differ radically from previous stories, it is possible that the accuracy of the estimate may decrease.

  • The accuracy of velocity is dependent on the knowledge and experience of the development team working together. Any changes to team composition will impact velocity and therefore future estimates.

  • Numbers used are team specific, and comparisons between teams can lead to confusion for stakeholders.

  • Relative estimates can be misconstrued as a definitive time to complete.

  • Stakeholders outside the team may focus on the estimates (output) instead of value delivered (outcomes).