PremierAgile

Developers and Estimation:

One of the aspects of a Scrum Development Team is to self-organize themselves and are expected to manage their own work. A crucial aspect is to estimate their work so that it gives predictability to the Product Owner and Stakeholders. In Scrum teams, two estimation approaches are commonly used: Ideal Hours and Story Point estimation.

The 'Ideal Hours' approach consists of estimating effort what we know today, and how long it would take if everything goes according to the plan. And since humans are not so great at estimating in terms of hours, usually Developers tend towards using Story Points which is a measure of the relative size of a User Story based on whatever information is known now.

In Agile projects, Story Points are used as units of work to estimate the complexity of a given User Story. An excellent way to size a User Story is to articulate it in terms of a known User Story or also called a reference User Story. This makes it easier for each Development Team member to size the relative complexity. This process of comparing a User Story with a previously estimated User Stories is known as triangulation.

Size:

The size of a User Story is a combination of 3 factors - C U E:

• Complexity
• Uncertainty - Lack of clarity of the User Story
• Effort

Developers may use one of the following series to size the User Stories in a Product Backlog:

• Natural numbers: 1, 2, 3, 4, 5 and so on.
• Even numbers: 2, 4, 6, 8, 10, and so on.
• Fibonacci series: 0, 1, 2, 3, 5, 8, 13, 21, 34 and so on.
• Modified Fibonacci series: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100.
• Or any other series.

Amongst these, the Modified Fibonacci series is the most popularly used series for sizing.

What are Fibonacci numbers?

The Fibonacci series consists of a sequence of numbers where each number is a sum of the preceding two numbers. The traditional Fibonacci sequence is 1, 2, 3, 5, 8, 13, 21, 34 and so on. In Agile projects, this series is modified. The modified Fibonacci series is 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 - a sequence that is used to estimate the relative size of User Stories in terms of Story Points.

Significance of the Fibonacci numbers in Agile sizing:

They are exponential

When estimating time, a shorter time span indicates more certainty (or clarity in the User Story), whereas bigger work items are more complex, and time estimates turn out to be less precise. An exponential scale enables just enough details for small tasks and indicates more uncertainty for large tasks.

User Stories with smaller sizes (less complexity and more clarity) can be estimated more effectively compared to User Stories that are more complex. As the numbers increase, the difference between two succeeding numbers also increases exponentially, which leads to less realistic estimates. This is similar to the characteristics of User Stories (or Product Backlog Items) whose complexity also increases as we move deeper into the Product Backlog.

The Fibonacci sequence is a lagging exponential sequence. It enables you to develop your estimates with increasing uncertainty as time increases, which results in an effective, efficient estimation.

Using the Fibonacci series turns out to be helpful in such cases because larger User Stories that lead to inconsistent estimates between team members can be now requested to break down into smaller User Stories. They can also be grouped to the nearest Fibonacci number of the analogous bucket in the backlog. Smaller User Stories have a smaller bucket difference, which results in a more realistic size (C U E).

They consist of integers

In Agile, both requirements and solution evolve over a period of time. So are the estimates (sizes of User Stories). The goal of sizing is to get a high-level estimate and get started. Thus, there is no need for the level of detail at a detailed decimal level. Trying to be accurate may slow down the team. After all, the Cone of Uncertainty says that the actual sizes of User Stories end up somewhere between +160% and -160% of the initial estimated sizes.

You need to choose more or less

Besides adding uncertainty for larger time spans, the Fibonacci sequence also compels your team to make a choice. For unclear User Stories, there has to be a 'this' or a 'that', and nothing in-between, which encourages your team to group and differentiate the size of User Stories. Moreover, the Fibonacci sequence has a varying distance between Story Points. For instance, the difference between 3 and 5 is 2, while the difference between 5 and 8 is 3. This enables you to intuitively differentiate the Fibonacci numbers as different magnitudes.

They are non-linear

Fibonacci numbers are non-linear in nature, which reduces the probability of over-analysis. Some of these numbers used in the Fibonacci sequence are prime numbers, which restricts your ability to compare or evenly break down tasks. Large User Stories are not squarely linked to each other, and the numbers don't indicate that the User Story would be twice as fast if you have multiple people working on it. This mitigates the chance of over-analysis.

Wrapping it up

Developers can have different experiences with different estimating sequences depending upon the sequence they use. However, majority of the Developers measure User Story in terms of relative size which is a combination of 3 factors namely C-Complexity, U-Uncertainty and E-Effort.

The technique that is used to size User stories is called Planning Poker. Developers play Planning Poker during Product Backlog Refinement, and during Sprint Planning if required. A Scrum Master facilitates Planning Poker and helps Developers makes decisions, while a Product Owner clarifies questions raised by the Developers.