How Agile Teams Use Fibonacci to Estimate Story Points
We focus on processes to effectively and efficiently develop digital products. One of our processes is using Agile Development, which includes using Agile Story Points to assign a common definition to the effort required to complete tasks.
Table Of Contents
What is the modified Fibonacci Sequence?
In this post, we’ll focus on the modified Fibonacci Sequence – 0, 1, 2, 3, 5, 8, 13, 21, etc – as an exponential complexity scale (good discussion on why, other than the cool name).
This definition of complexity should be shared by a whole team, from developers, product owners, project managers, executives, to anyone else who’d like to understand the nuances and complexities of developing digital products within this framework. The framework allows you and the organization to have visibility into timelines, complexity, budget, and staffing.
Why Use the Fibonacci Sequence for Estimation in Agile?
Why do we need this? Because humans are bad at estimating effort, especially when complexity increases. In software development, large features have hidden complexities that don’t become apparent until one is “in the weeds.”
However, every team is different. The purpose of using Agile Story Points is to agree on software project estimates in order to most effectively plan and execute product development (sprints, tasks, etc.).
Agile Story Points: Modified Fibonacci Sequence
0 – Very quick to deliver and no complexity. In minutes
1 – Quick to deliver and minimal complexity. An hour
2 – Quick to deliver and some complexity. Multiple hours
3 – Moderate time to deliver, moderate complexity, possible unknowns
5 – Longer time to deliver, high complexity, likely unknowns
8 – Long time to deliver, high complexity, critical unknowns
13 – Long time to delivery, high complexity, many critical unknowns
21 – You’re doing this wrong. ;)
Final thoughts
As you can see, this is not clear cut and leaves much room for interpretation. Estimating software development is difficult, and there are many factors to consider, including complexity to develop given existing architecture, team availability, business priorities, unforeseen third party complexity, use of CD (Continuous Delivery)/automated testing, etc.
What teams should strive to do is build a culture where there is a good grasp on the solution, and all agree on definitions for the level of effort required to deliver each piece of functionality, task, bug fix, etc.
There are many topics which are not covered in this post, such as discussing spikes, the purpose of sprints in CD environments, and much more. Many digital developers also utilize Waterfall Methodology vs Agile Development. Waterfall Methodology is relegated to very specific projects where the luxury of quickly iterating and adapting is not available – think ‘building a plane’.
The main takeaway of this post is to start implementing Agile Story Points in your projects; research, learn, iterate, and figure out what works best for your team(s) and organization(s).
