To begin with what agile estimation is, we need to understand the need for estimation in the first place. Estimating work gives us a clear idea of the complexity involved, the effort required, and the risk or uncertainty of the requirement that needs to be completed.

Why is agile estimation important?

Agile estimation is important for several reasons:

• It helps teams to align their work with the customer’s needs and expectations.
• It helps teams to plan and execute their sprints effectively and deliver value incrementally.
• It helps teams to communicate and collaborate better with each other and with stakeholders.
• It helps teams to improve their performance and quality over time by learning from their estimates and feedback.

Absolute estimating in traditional environment

Absolute value is a fixed and unchanging measurement. For instance, stating that an object is precisely 10 centimeters long, a book contains exactly 20 pages, or a room measuring precisely 20 feet in width represents an absolute value. This fixed nature remains constant and is not influenced by external factors.

In traditional project management, such as waterfall, where requirements are defined before development, every requirement is well-known beforehand due to its detailed planning. In this approach, a specific unit of time or an absolute value can be assigned to each task or requirement. This method is referred to as absolute estimation.

An example of absolute estimation could be specifying that a particular task will take precisely 8 hours to complete.

Absolute estimating can be useful for small and well-defined tasks. However, it has drawbacks for agile projects, as tasks are defined and delivered within specified, time-boxed iterations.

Relative estimating in agile environment

Relative values involve comparing one value to another, creating a scale that indicates the relationship in size or magnitude between two things. For example, consider two books where one is twice as thick as the other; this comparison illustrates the concept of relative scale.

Relative scale involves comparing sizes or values in relation to something else. 

Unlike traditional management that uses absolute values as mentioned above, Agile project management particularly works very well in complex environments where requirements keep changing(evolving) based on the feedback. Which is why, Relative estimating is a more agile method.

Instead of assigning a fixed amount of time or effort to each task, Agile estimation involves comparing tasks to each other and assigning relative values.

For instance, you might say that a user story is twice as big as another one, or that a bug fix is half as complex as a new feature.This approach enables teams to prioritize work, allocate resources, set expectations, and monitor progress. 

Here is what Agile estimation is about.

Agile estimation is not about predicting the exact time or effort required to complete a work item, but rather about comparing it with other work items and finding a suitable measure of its value.

There is no perfect value for estimation, as numerous factors must be taken into consideration when estimating a specific task or requirement. 

Consider the example where an experienced team member can complete Task A in 8 hours, while a fresher might need 16 hours for the same task. Similarly, Task B might take a fresher with the right skills 10 hours, but another experienced team member lacking that specific skill could take 15 hours.

To address these variations, teams need to reach a consensus.  For example, finding a middle ground between the estimated values or adjusting the estimation for the next task based on the team’s collective understanding. In this way, the compared values are always relative, reflecting the varying skill levels and circumstances within the team.

Measuring effort through story points

All okay. Till now it’s all about absolute values and relative values, But how do you measure the size of a work item in agile to compare the work items?

Through story points.

Story points are a unit of measurement that represents the complexity, uncertainty, and risk involved in completing a work item. In simple terms, they are the way to express the estimate of the effort that it takes to complete a PBI. They are not based on hours or days but on a scale that reflects the relative difficulty of the work.

Thus it is not important what number you have assigned to the story point. You can assign 1 or 100 or a million as a story point value. It doesn’t matter. But what matters is that the assigned value must be able to measure the relative difficulty or effort that goes into completion of the task. 

That is, if Task A is assigned with 1 story point  and Task B with 2 story points,  then it means that Task B will take double the effort to complete the task. The greater the number assigned, greater is the complexity involved in completing  the task.

So, which is that number on the scale that measures the complexity involved?  And How do you address this complexity?

To address this,  most of the teams use sequence numbers as their relative scale such as Fibonacci or Doubling Sequence.

One of the most popular scales for estimating story points is the Fibonacci sequence

Leveraging the Fibonacci Series for Agile Work Sizing

The Fibonacci series is a mathematical sequence of numbers that starts with 0 and 1, and each subsequent number is the sum of the previous two numbers. For example: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, and so on.

The Fibonacci series has many applications in mathematics, science, art, and nature. But how can it help you size your work in agile?

The Fibonacci sequence has some interesting properties that make it suitable for agile estimation:

Reflecting Uncertainty and Variability

The Fibonacci sequence mirrors the uncertainty and variability in estimating work items. As work items grow, the increasing gap between numbers signifies greater room for error and adjustment.

Encouraging Breakdown of Large Work Items

The series promotes breaking down large work items into smaller, manageable pieces. If a work item exceeds a series number, it signals that it needs to be split into more digestible tasks.

Imagine you have a big task to complete, like building a treehouse. The Fibonacci sequence is like a set of building blocks that helps you make this big task more manageable.

Suppose building the entire treehouse is like reaching the number 21 in the Fibonacci sequence. That’s a big task! But, the sequence encourages us to break it down into smaller parts.

For example, let’s focus on the numbers 8 and 13 in the sequence. If we think of these as smaller tasks related to building the treehouse, like assembling the walls and adding the roof, it becomes more manageable. We can break down the big task into smaller steps.

So, when using the Fibonacci sequence for agile estimation, if a work item (like building the treehouse) becomes too big and reaches a Fibonacci number like 21, it signals that we should break it down into smaller, more digestible tasks. This makes it easier to plan, track progress, and work on one piece at a time.

Exponential Increase in Complexity

As the series progresses, numbers increase exponentially, highlighting the growing complexity of estimating larger work items. This underscores the challenge of accuracy in larger and more intricate tasks.

Let’s break it down with an example. The Fibonacci sequence starts with 0 and 1, and each subsequent number is the sum of the two preceding ones. So, it goes like this: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, and so on.

Now, consider the difference between consecutive numbers. The difference between 5 and 8 is 3, as 8 – 5 = 3. However, the difference between 21 and 34 is 13, as 34 – 21 = 13. You can see that the differences between consecutive numbers are increasing (3, 5, 8, 13), showing that the complexity and difficulty in estimating the next number grow significantly.

This pattern illustrates the challenge of estimating larger and more complex work items. The larger the numbers get in the Fibonacci sequence, the more difficult it becomes to predict the next one accurately. This mirrors the real-world challenge of estimating and managing increasingly complex tasks as they become larger. 

Avoiding False Precision and Anchoring Bias

When estimating things, it’s important to avoid two common mistakes: False Precision and Anchoring Bias.

False Precision is like giving too many details to estimates, making them seem more accurate than they really are. For example, if a project manager says a task will take exactly 47.5 hours, it might sound very precise, but may not consider the uncertainties such as testing phases, or team discussions. This will cause a delay in the project than expected. That means the manager’s estimate is false.

Now, there is another situation called Anchoring Bias where people rely too much on a prior piece of information, called the “anchor,” leading to biased decision-making.

To handle both these issues, we use the Fibonacci sequence. Instead of giving very specific numbers, like saying a task has exactly 11 or 12 story points, we round it to the nearest Fibonacci number, like 13. This makes the estimate simpler and more flexible for uncertainties in the project, preventing us from getting too fixed on specific numbers.

Using Fibonacci sequence as an estimation scale in scrum

To use the Fibonacci sequence as an estimation scale in scrum, you need to assign a Fibonacci number to each task based on how complex and difficult it is compared to other tasks.

Consider a scenario where two developers, Alice and Bob, are working on a Scrum team. They are tasked with estimating the effort required to complete a user story that states, 

“As a user, I want to be able to search for products by name.”

Steps in Estimation Process

Product Owner explains the user story: The Product Owner provides a clear explanation of the user story, ensuring that both Alice and Bob have a shared understanding of the requirements.

Team discusses and asks questions: Alice and Bob discuss the user story and ask clarifying questions to ensure they have a complete understanding of the task. They consider potential complexities and dependencies.

Independent estimation: Each team member independently estimates the effort required for the user story using the Fibonacci sequence. They write their estimate on a piece of paper or card.

Reveal estimates: Alice and Bob simultaneously reveal their estimates to each other.

Alice estimates 5 story points for the task. She reasons that the search functionality is relatively simple, but there may be some complexity in integrating it with the existing product catalog and handling special characters in search queries.

Bob estimates 8 story points for the task. He reasons that the search functionality should be robust and efficient, considering the potential volume of products and users. He also anticipates the need for thorough testing to ensure the search results are accurate and relevant.

Discuss and reach consensus: Since their estimates differ, Alice and Bob discuss their reasoning and try to reach a consensus. Alice explains her concerns about potential complexities, while Bob emphasizes the importance of a robust and efficient search feature.

After discussing the task further, they decide to estimate the user story at 5 story points. They agree that the initial focus should be on implementing the basic search functionality, and they can address potential complexities and performance optimizations in subsequent iterations.

This example illustrates how the Fibonacci sequence provides a flexible framework for estimating effort in Scrum. By considering the relative complexity of tasks and using a non-linear scale, teams can make informed estimations that align with the iterative nature of agile development.

Conclusion

In closing, using the Fibonacci sequence to size up your tasks isn’t just about numbers; it’s a smart move for accuracy. Teams can ditch strict timelines and go for a flexible approach that matches the changing nature of your projects. It helps you break down complex tasks into manageable parts ensuring your estimates adjust with your workload. It’s not about being super precise; it’s more about comparing values, working together, and staying adaptable. So, why stick to strict rules when the Fibonacci sequence can be your agile sidekick, adding flexibility to how you estimate your projects?