10 Reasons To Use Fibonacci Sequence For Story Points

Planning poker simplifies the estimation process and reduce the time taken for the estimation considerably. Unlike other top-down, bottom-up breakdown method, it combines expert judgement, historical references and team level factors to arrive at the estimates. Story Points, Budget and Forecasting.

By Vijay Kulkarni

Planning poker is another great technique to validate that everybody in the team is on the same page. The People Who will Perform the Work Make the Final Estimate In Scrum the person who plays Product Owner role cannot commit to deliver a feature on certain date before letting the development team to estimate it first. Planning Poker® is Meant to Encourage Conversation and Shared Understanding. One of the main benefits of Planning Poker® is to enable members of the team that may have different skillsets to provide their perspective on the complexity of a particular story and identify gaps in understanding within the team. If someone points a story as a 1.

In this blog we will discuss the need for estimation in an agile project and merits of using Fibonacci series as scale of estimation.

Need For Estimation: Predictability

“When will you deliver the project?”

“How can you ask that question? We are Agile”

Typical conversions in a project, isn’t it?

Finite resources

Any project comes with finite resources in terms of budget or money, time to delivery, delivery schedule, team members, skills etc. The typical business or customer expectation is always more, faster, cheaper and better. It becomes an obvious requirement to deliver maximum outcome using the available finite resources.

Time To Market

Businesses are in competitive market and 'Time To Market' is critical factory for winning over the competition. Business and customer would like to see a predictable delivery schedule. Predictable delivery will help the business to set right expectations with the customers and keep the promises by delivering on those expectations.

Team's pace of delivery

Development team would also want to know their speed or pace of delivery so that they can commit to work and then deliver it on their commitment.

Story Points

Typically story points are used as unit for ‘Size of Work’ during the story estimation. Story points represent an imaginary unit.

Story points are subject to a particular team. You should not try compare story points of one team with other team. For example, one team may estimate a story at point 8 and other team may say that it is a 13 points story for them. Story points are team specific.

Story Points Scale

Agile estimation uses abstract units. Various number sequences and series are used for the estimation of size of stories. Some of the common sequences are as below:

Fibonacci series: 0, 1, 2, 3, 5, 8, 13, 21…

Modified Fibonacci series: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100…

Power to two: 0, 1, 2, 4, 8, 16, 32, 64…

Series of five: 0, 1, 2, 3, 5, 10, 20, 40…

T-Shirt sizes: XS, S, M, L, XL, XXL

Three buckets: Small, Medium, Large

Physical Relationships: Pebble, Rock, Boulder, Mountain, Dog names, Cat names

Velocity

The whole purpose of story point estimation is to know the velocity of the team. Velocity of the team can be used by development team to commit the work in a sprint and product owner can use it for budget and forecasting purpose. Consistent velocity shows consistent throughput by a team.

Team velocity is just average of past few sprints (typically three sprints). Let’s say a team velocity is 30 points and sum of total story points in product backlog is 120 then it is roughly 4 sprints worth of work. The development team can choose the work to fit in the next sprint based on the ‘yesterday’s weather’.

For velocity to make sense

  • Story points are estimated using one of the fair method like planning poker or affinity estimation
  • Team's composition should remain stable for a sufficiently long duration
  • Type of work team strives to do during sprints remains similar
  • Team is self-organizing
  • The refinement sessions are taken seriously and conducted regularly
  • The product owner is available to the team whenever needed

While estimating, the story in discussion is relatively compared with rest of the stories in product backlog. When you consider it as relative estimation, the story sizes are estimated with relative to each other. For example, a story estimated at points 8 is generally larger in size as compared to story estimated at size 5 and smaller in size as compared to story of points 13.

Planning poker simplifies the estimation process and reduce the time taken for the estimation considerably. Unlike other top-down, bottom-up breakdown method, it combines expert judgement, historical references and team level factors to arrive at the estimates.

Story Points, Budget and Forecasting

Following simple formula can be used to derive the number of days a team would roughly take to deliver a piece of work. Product owners can use these formula to come a roadmap for a project.

Number of days = Total story points / Team velocity X Number of days in sprint X Team size

Hours vs. Points

In a typical development team, the productivity of all the developers is never identical. What one developer can achieve in X hours the other developer may not do same amount of work.

Focusing too much on clock hours is a kind of accounting system and lead to misconception of the true essence of team work. It may easily lead to focus on number of hours on the chair, not work actually achieved.

Fibonacci Series

A typical question most of the newbies introduced to planning poker come up with is - “after all if we are using numbers for story pointing, why just not use the normal number sequence of 0, 1, 2, 3, 4, 5, 6 and so on. Why do we need to use series of numbers similar to Fibonacci series?”

Fibonacci series, though it look like mysterious series of numbers with some magical abilities, very simple to understand and it is not that complicated. A typical Fibonacci series starts with 1, 2 and every number after that is calculated by adding two previous numbers. So the Fibonacci series is 1, 2, 3, 5, 8, 13, 21, 34, 55.

Mathematically Fibonacci series is 1, 2, 3, 5, 8, 13, 21, 34, 55. But this Fibonacci series is typically not used as is during planning poker. Many teams use slightly modified version of this Fibonacci series. The modified Fibonacci series is 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100.

There are multiple reasons why Fibonacci series is popular for story pointing.

Planning Poker - Wikipedia

Natural Rhythm

Fibonacci series occurs in nature (Fibonacci number). There is a natural rhythm to the progression of Fibonacci sequence.

Fibonacci Series Resembles Product Backlog

In a typical product backlog, the stories at the top are more granularly refined as compared to stories towards the bottom. The Fibonacci series reflect this granularity quite good.

The increasing gaps in the Fibonacci series justify the principle of estimation of “being roughly right over being precisely wrong”. In practical terms, we should use ranges with a degree of uncertainty rather than using absolute units.

The numbers in Fibonacci series are not evenly distributed, as we go down the Fibonacci series the numbers get bigger. The jumps between the sizes gets much bigger as the stories gets bigger. Similarly, the stories in a product backlog are smaller and more refined at the top and as we go down in the product backlog the stories get bigger and bigger.

In a way, a story with size 2 is slightly bigger than story of size 1 but a story of size 13 is much bigger than a story of size 8.

This way Fibonacci series kind of brings that scientific approach and logic to the planning poker and pointing system. For this reason, Fibonacci series in much suitable approach for story pointing as compared to the regular numeric scale.

Uncertainty grows with complexity; the bigger the estimate, less precise the option. It forces you to further break down the task, if you want to get near precise estimate or to fit the story in a sprint. Fibonacci series fights against the human nature of deciding that a '4' is 'twice as big' as a '2' because it's twice the number value

Problems don't grow in sequence

You know that one problem is hardly the exact same size as of other problem. Also, one problem may not be always exactly double or triple the size of other problem. In Fibonacci series as well, number are not exactly doubled but there is exponential growth as the series expands.

For example, a new problem to be estimated is bigger than a problem already estimated at 2 points; how big is the new problem, if it is smaller than double then it could 3 points, if it is bigger than the double, then it could be 5 points.

Humans are bad at estimation but good at comparison

Benefits

Humans are usually very bad in estimation but pretty good on comparison. I’m sure you can easily get the size (S-M-L) of the T-Shirt of your friend compared with your T-shirt but pretty hard to guess how many centimetres are his shoulders.

Let’s say, if I ask you to tell me the distance between the door of your room and the window, by just looking at it, I am sure you will be able to take fairly accurate guess of it in the unit of feet. You may be off by few inches here and there. But if I ask to you tell me the distance between New York and Washington then high level ball park distance in miles are sufficient, the expectation is not to be accurate up to a great degree.

Hence Fibonacci series do better than the linear scale as the lower number a densely populated than the higher numbers. Fibonacci series in sensitive to smaller numbers as compared to larger numbers. In other words the magnitude to error in higher order of estimate is greater than the detailed smaller estimates.

Accurate estimate is oxymoron

Accurate estimate is oxymoron either estimate or accurate.

Cone of uncertainty says that accuracy of estimates in the beginning of the project is very less and variability factor is very high. Due to which we should only estimate at a high level and evolve as we go deeper in the projects.

Estimations are ‘never’ there for accuracy. While estimating, you should not try to be precise and come with an absolute value but you should try to come up with a value in a range. Working with ranges is complicated. Just taking average of range is not a good idea as you are again trying to achieve absolute number. Fibonacci series have this range concept baked in the sequence itself. For example if you come up with story points of 8, that means you are somewhere in the range over 5 and under 13. If you come up with story points of 13, that means you are in the range over 8 and under 21.

Low of large numbers

As per Wikipedia the low of large numbers is described as below:

In probability theory, the law of large numbers (LLN) is a theorem that describes the result of performing the same experiment a large number of times. According to the law, the average of the results obtained from a large number of trials should be close to the expected value, and will tend to become closer as more trials are performed.

Typically when estimating large number of user stories, there are chances some of the user stories may get underestimated, for example, a story estimated at 8 points my turn out to be bigger than other average 8 pointer stories; or vice a versa, some stories my get overestimated, for example, a story estimated at 13 points may turn out to be less than worth of other average 13 pointer stories. In this case, a large number of stories, the law of large number will kick in effects pushing the aggregate of the consolidated story points towards the centre.

Faster Estimation

Using planning poker, the estimates are derived and owned by the group. In this case the group is the scrum development team. One single person of the development team is not responsible for the final estimate but it is collective ownership.

To estimate as group the team need to quick and easy way to arrive at the censuses. If the group try to estimate the stories at linear scale, then there will be too many arguments and time taken to agree on a single precise number. Deriving a precise number will again produce precisely wrong estimate. There is not much of difference between numbers 6 and 7.

Hence the ranges in Fibonacci series help to resolve this issue. To pick a number between a choice of 5 and 8 is easy. You have only two choices. This way Fibonacci series helps in faster estimation.

Disassociate From a Formula

Arguably, a geometrical progression formula can also be used, for example, double the number as compared to previous number, but human mind associate the a formula with scale of numbers.

With Fibonacci series, the formula is not that evident. Psychologically human mind is less likely to attached ‘time’ to the numbers Fibonacci series.

Many teams go further and instead of “points”, refer to more abstract things, such as “this task is 8 sunflower seeds of work”, or “we think the complexity is 5 puppies.” By doing this, they make it even harder to people to attach times to tasks. No one would ask “how many hours is a puppy?”

Disadvantages non-numeric scales

Sometimes, when people are new to modified Fibonacci series story pointing scale, it creates confusion. Some people try to find relation between the numbers in Fibonacci series to clock hours.

The numbers in Fibonacci series do not represent the absolute clock hours but they are just relative sizing when the stories in a particular product backlog are compared to each other by a team.

To avoid this confusion, some teams choose alternate scales like below.

T-Shirt sizes: XS, S, M, L, XL, XXL

Three buckets: Small, Medium, Large

Planning Poker Benefits

Physical Relationships: Pebble, Rock, Boulder, Mountain, Dog names, Cat names

Though these measures are familiar and less abstract than Fibonacci series story points, following are some of the disadvantages of using non-numeric scale for story pointing:

  1. With non-numeric scale, there is no comparison units between two adjacent options. For example, it is easy to compare 5 with 8 but is not so easy to say how big is L as compared to M. Members of the development teams may have different perception of relative sizing between L and M.
  2. These non-numeric scales are almost evenly distributed. Evenly distributed scales do not provide the benefits that Fibonacci series provides by reflecting the granularity of product backlog from smaller to larger and larger.
  3. It is easy to add up numbers and present the total size of the work. Summing up non-numeric options is not possible unless their numeric equivalents are defined.
  4. The playing card decks for these measures may not be easily available and you may need to make one of your own.

Culture, Skills, and Capabilities // How to become a more data-driven organisation

In our whitepaper “How to become a more data-driven organisation”, we wrote about the five steps that an organisation would need to take, which are: Outcomes: Defining goals and metrics to ensure clear and measurable outcomes Analytics: Implementing and sharing the analytics to improve data-driven decision making Innovation: Testing assumptions through hypothesis testing and learning Data Platform: Gaining new insights

Planning Poker Benefits Plan

Read More »