Estimating agile projects: The Fibonacci way
In mathematics, the Fibonacci numbers are the numbers in the following integer sequence:
1, 1, 2, 3, 5, 8, 13,21,34,55,89,144.........
This is called the Fibonacci series, and is characterized by the fact that every number after the first two is the sum of the two preceding ones:
The Fibonacci series is named after Italian mathematician Leonardo of Pisa, known as Fibonacci. His 1202 book Liber Abaci introduced the sequence to Western European mathematics, although the sequence had been described earlier in Indian mathematics.
I decided to try out the Fibonacci sequence for estimating story points for my project and it really helped. A few years back, I was working on a project that involved team members who were not comfortable giving estimates for their work. As Project Managers, we would agree that we all need some high-level estimates to understand the approximate size of the product we would be delivering. Developers, through years of experience, develop the expertise of giving good estimates. For a beginner, this is always a challenge.
A good estimation can give the product owner a better insight into the level of effort for each work item. The estimated story points together with its priority helps the Product Owner to select which story points need to be delivered as part of which iteration. If you have worked on scrum based projects, you would be familiar with the Fibonacci sequence of numbers for arriving at the high-level estimation of your story points.
How can we use Fibonacci sequence in high-level estimation?
A modified version of the Fibonacci series is usually recommended for estimation of Agile user stories. The series looks like this:
1,2,3,5,8,13,40,100......
Estimation for agile projects is a team effort. Unlike traditional teams, agile teams give their estimation in term of story points. The team first prioritizes the story points (Story point is a term used by Scrum teams to measure the effort required to implement a story). We then assign story points to each of the stories based on the effort that will be required for it to complete.The sizing in terms of Story Points is done on a relative scale.
I would assign 1 point to the story which requires least effort and 100 to the one that requires the most effort. Remember that Story points are estimated based on the effort required to complete the story and not based on the complexity of the story.
So for my project which has 6 user stories for the 1st Iteration, I assigned the following Story Points.
User Story 1 was assigned 5 Story points
User Story 2 was assigned 8 Story points
User Story 3 was assigned 2 Story points
User Story 4 was assigned 1 Story point
User Story 5 was assigned 13 Story points
User Story 6 was assigned 100 Story points
A point to note here is that if a particular story is assigned 100 points, then it is time to break it down further to smaller stories. The more granular your stories can be the better it is for the team to understand the effort required to complete the story.
Advantage:
While implementing the Story Points using Fibonacci sequence, I realized that the biggest advantage was the fact that the designer, architect, developers, testers would all align to the effort required to complete each story. Story Points enable people coming in from different background to mutually arrive at the relative effort of each story using the Fibonacci sequence. The team can use Planning Poker method to arrive at the Story Points.
Translating points to hours
As Project Managers, we normally tend to translate these story points to hours. There is always a debate whether to translate points to hours or not. Hours are more granular and are better estimated at task levels. In case of our project, we assigned tasks for each User Story and assigned hours based on the task. We did a reverse check to validate the estimation hours are aligned to the effort based points assigned to each User Story.
What was the need of using Fibonacci series?
I decided to use this because of the uncertainty involved in the project. I feel that Fibonacci is best used for projects having uncertainties and complexities involved. This means that when we assign a low amount of points to a story or task, we are more certain of the context, difficulties, and attributes of that task than when we assign a high number. It also gives us better precision. For E.g when we say a story has 2 story points another one has 4, it implies that the second story will require twice as much effort as the first. With Fibonacci sequence, we get numbers like 3 and 5 which might be more accurate in terms of story point assignment. So for me, Fibonacci sequence gives a comparatively better precision.
Best practice for agile estimates
During Retrospectives sessions of a sprint, it is a good practice to revisit the estimates. You can re-calibrate the estimate. Evaluate the story points and see if they were accurate. If not, re-estimate those stories. Some agile tools like would record the story points and helps us and revisiting the estimates for subsequent iterations.
Note: For the glossary of Scrum Terms refer to the scrum glossary.
