Using the Fibonacci Scale in Agile Estimation

What is the Fibonacci sequence?

Fibonacci was an Italian mathematician in the Middle Ages who wrote a book called Liber Abaci (Book of Calculation) a “cookbook” written for tradespeople on how to do calculations. This book introduced and popularized the Hindu-Arabic numeral system in the Western world. In Liber Abaci, Fibonacci also presented the following problem:?

“A certain man put a pair of rabbits in a place surrounded on all sides by a wall. How many pairs of rabbits can be produced from that pair in a year if it is supposed that every month each pair begets a new pair which from the second month on becomes productive?”

To estimate the answer, Fibonacci introduced an exponential sequence of numbers, now known as the Fibonacci number or Fibonacci sequence. In the sequence, each number is the sum of the preceding two numbers:

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

When and How to use Fibonacci series is used in Agile?

The Fibonacci sequence is found in many different disciplines and in nature. For example, it has been used to describe plant life growth, estimate population increases over a specified timeframe, model virus breakouts, and predict the behaviour of financial markets.?

One may ask… what does this long string of numbers have to do with Agile planning? Essentially, the Agile Fibonacci scale gives teams a more realistic way to approach estimates using story points. Story points are used to represent the size, complexity, and effort needed for completing or implementing a user story. Each story point is assigned a number from the Fibonacci scale. The higher the number, the more complex the story point, and presumably, the amount of effort it will take to complete.

The Scrum Team usually get together at Refinement, before Sprint Planning, to size the work they are accountable for delivering. The team discusses each user story and assign a number from the Fibonacci scale that correlates to the overall size. They use everything they understand about the requirement at that point in time and what is expected to get the requirement done. This is called Story Pointing.

Story Points represent the complexities, uncertainty, and efforts (CUE) needed for completing or implementing each product backlog item.?The higher the number, the more?complex?and?uncertain?the work, and presumably, the amount of?effort?it will take to complete. For example, 1 Story Point means that CUE is minimal, and the story can be delivered quickly, perhaps in one day or less. On the other hand, an item assigned 13 Story Points means it is very complex and could take multiple weeks to complete.?

Why Use Fibonacci Story Points in Agile?

When using the Fibonacci scale in Agile settings, your team can experience the following benefits:

• Using the Fibonacci scale scoring method leads to faster estimation over time, and a big win for your team.
• Using these factors in planning takes the guesswork out of estimating, letting you more accurately scope effort.
• The team gets a better grasp of what’s required of them, making it easier to develop a sound implementation strategy.
• The team won’t over plan, so they have a better chance of finishing an increment.
• The team knows how much to plan in a sprint, thereby letting them work at a sustainable pace.
• The team can create a reasonable estimate without having to commit to a specific timeframe.
• Fibonacci scale scoring method establishes a scale for comparing an item’s complexity, uncertainty, and effort
• This approach also ensures the whole team are involved in the estimation process; therefore, includes everyone’s perspectives
• The exponential nature of the Fibonacci Scale makes it easy for the entire team to understand what the assigned numbers mean to them and their unique domain.

Key-point pitfalls to note and how to avoid them

It’s not all easy in story point land. Story points streamline the?project management process, but only if you avoid certain mistakes when estimating.?

• The relative nature of story points makes understanding how tasks compare to each other easier for your team. It is important not to assign points arbitrarily. Always remember that story points should scale relative to each other.
• Avoid using hours for your story points estimation. Instead, consider factoring in the complexity, risk, and repetition of those requirements to determine your story point values.
• If your team’s story point estimations don’t match up, avoid the danger of taking the average of the points for estimation. Instead, have further conversation with your team to discuss the discrepancy. Once you have a better understanding of why the estimations don’t align, you can find a story point everyone agrees on.?
• Avoid the temptation of assigning story points to user stories that are too large. If a user story is too large, it may be worth breaking it down further. Always remember the INVEST criteria - S stands for small. A user story needs to be small so as to fit within an iteration. The ultimate determination of whether a story is appropriately sized is based on the team, its capabilities, and the technologies in use.
• Always ensure that team members have full clarity about the expectation for the story point values. Story estimation is not useful if your team doesn’t have a common understanding of the story points.

Fibonacci scale scoring point estimation?are important part of the project management puzzle. But correctly estimating effort and getting tasks to the finish line is a lot easier when your team have a common understanding of the process to represent the size, complexity, and efforts needed for completing or implementing the user story.?

Do you have a workable approach of user story estimation in your team? I hope you enjoyed this edition? Please let me know your thoughts.