Agile - Story Points

In this Article we will cover the below topics:

1) What are Story Points in Agile?

2) Detailed Explanation of Story Points?

3) Fibonacci Series?

4) Why are Story Points given in Fibonacci series?

1)Story Points

Story points in Agile are a unit of measure used by Agile development teams to estimate the relative complexity or effort required to complete various tasks, user stories, or features within a project.

2)Here's a more detailed explanation of Story Points in Agile:

1)Relative Estimation: Story points are used for relative estimation, not for predicting exact timeframes. Teams assign story points to tasks or user stories based on their perceived complexity and effort required, in relation to other tasks or stories. This allows for a relative comparison of work items rather than trying to estimate how many hours or days each one will take.

2)Fibonacci Sequence: Teams often use a scale based on the Fibonacci sequence (e.g., 1, 2, 3, 5, 8, 13, 21, etc.) to assign story points. The choice of the Fibonacci sequence helps emphasize that the further apart two numbers are, the less certainty there is about the estimation. It discourages overly precise estimates and encourages discussions among team members.

3)Team Consensus: Estimating story points is a collaborative effort involving the entire Agile team, including developers, testers, and other relevant team members. Team members discuss the requirements and potential challenges to arrive at a consensus on the appropriate story point value for each item.

4)Velocity: Over time, teams track how many story points they complete during each sprint or iteration. This historical data is used to calculate the team's velocity, which helps with release planning and predicting how much work can be accomplished in future iterations.

5)Size and Complexity: Story points consider various factors, such as the size, complexity, and uncertainty of a task. This holistic view allows teams to account for both technical and non-technical challenges when estimating work.

6)Transparency and Communication: Story points enhance communication within the Agile team and with stakeholders. They provide a common language for discussing and managing work items, making it easier to prioritize and plan the development process.

3)Fibonacci series

Fibonacci series: In the sequence, each number is the sum of the preceding two numbers:

0, 1, 2, 3, 5, 8, 13, 21

Essentially, the Agile Fibonacci scale gives teams a more realistic way to approach estimates using story points. The higher the number, the more complex the story point, and presumably, the amount of effort it will take to complete.

4) Why are Story Points given in Fibonacci series?

Agile Fibonacci Scale is exponential rather than linear, it helps teams to be more realistic when looking at larger, more complex tasks.

To help you understand why the exponential nature of the Fibonacci series is helpful, we’ll paraphrase an analogy used by Mike Cohn, one of the founders of the Scrum Alliance:

Example:

Imagine holding a one-pound weight in one hand and a two-pound weight in the other. Without looking, you are likely able to determine which is which because the 2-pound weight is noticeably heavier—the two-pound weight is 100% heavier than the 1-pound weight).

If you were to hold a 20-pound weight and a 21-pound weight, it is harder to determine which is heavier because the difference between the weights is not that significant—the 21-pound weight is only 5% heavier.

Each number in the Fibonacci scale is exponentially larger (by about 60%) than the previous number. Teams can more easily recognize the differences and define the complexity of each story point.

5)Story Points don’t follow the Fibonacci sequence strictly. Because of this, it requires some adaptations:

Fibonacci — 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, etc

Story Points — 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100

It’s not black and white. Some teams will use the classic Fibonacci sequence, while others will use the adapted one. In practice, it doesn’t matter because both lead to the same result.

The idea is that the bigger the number, the less you know. As a product leader, whenever I see an estimate higher than 13, I understand the team lacks clarity and needs to work on understanding the problem space more. Larger numbers show me that I need to break the work into smaller pieces to aid progress.