What is Fibonacci Agile Estimation?
Fibonacci agile estimation is a combination of two concepts: the Fibonacci sequence and Agile estimation. Let’s quickly define these two things before putting them back together:
Agile estimation – is a method for providing some rough sense of effort (level of effort) so a Product manager can properly prioritize that work, considering both the impact and effort. Typically this is done with relative user story points rather than concrete hours, to encourage teams to make estimates, without fear they’ll be held to their precise estimate later.
The Fibonacci sequence is a popular number series that conventionally involves adding the previous two numbers to determine the next. It typically takes the form 0, 1, 1, 2, 3, 5, 8, 13, and so on. This scale is a popular tool for estimation in Agile.
Putting them together, Fibonacci sequence describes the number of points that a team may use for estimating the relative level of effort for a given task.
Why Consider Fibonacci Agile Estimation
To understand the usefulness of Fibonacci agile estimation, Mike Cohn’s article on the topic will be quite illuminating. It explains why using the Fibonacci scale for story point estimations leads to better estimation.
Working with Weber’s Law, Cohn asks the reader to imagine carrying two weights – one in each hand. One of these measures one kilogram (2.2 pounds) while the other weighs two kilograms (4.4 pounds). It is easy to tell which hand holds the heavier weight without looking.
However, the story changes when you are handed weights of 20 kg and 21 kg. It becomes harder to tell the bulkier one, even though the weight has increased by the same one kilogram.
The reality is that the changes were relative. The increase was 100% in one case and 5% in the other. This explains why one was more noticeable than the other.
The foregoing justifies the use of the Fibonacci sequence for story point estimation in Agile. It explains the rationale for Cohn’s suggestion of a modified sequence that has wider intervals but grows at a consistent rate of about 60%.
You can start increasing numbers in the series by 60% from the number, 2. This, Cohn argues, based on Weber’s Law, would make difference in efforts more notable or significant along the scale. You will have fewer numbers to choose from, thereby improving chances for consensus among team members.
It can become somewhat confusing if you used a scoring scale with regular intervals – for example, one that increases by two for every succeeding number. Take a case where everyone on the team agrees that a task will be hard to implement. On a scale of 2 to 100, a score of, say, 80 may indicate a certain level of difficulty perception by one person – 74, 84, or even 90 may capture it better for another.
So it can be seen that a modified Fibonacci sequence increases the chance for consensus in agile estimation.
Estimation Should Be Collaborative
The work of teams is interconnected. What one does influences what another does. This is why an emphasis is often placed on the need for collaboration to enhance success.
Product Owners, for instance, have a duty of gathering requirements, but they cannot estimate the amount of work that goes into executing them. The engineering team must come in when trying to estimate efforts and, of course, they need to have the requirements first.
Collaboration lets everyone have an opportunity to guide proper estimation. If you are contemplating design changes, for instance, you do not only need the input of designers but also that of developers and/or testers.
