Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Use a 4 in the modified fibonacci sequence

Last post 04:16 pm January 24, 2023 by Chuck Suscheck-PST
4 replies
08:53 am January 20, 2023

Hi

We are estimating our PBIs with the modified fibonacci sequence (0.5, 1, 2, 3, 5, 8, ...), which is working pretty well.

But there are often situations where a 5 is too high (compared to other PBIs) and a 3 too low. A 4 would fit perfectly.

Is there anything against with adding a 4 to the sequence, as long as everybody in the team knows the difference between a 3, 4 and a 5?

Thank you.


06:55 pm January 20, 2023

Give it a try. It's conceivably possible there's a meaningful discussion to be had by Developers when estimating if something is a 3 or 4, or 4 and 5.


07:47 pm January 20, 2023

There are no "rules" so if the team wants to do it, then go ahead.  However, remember that the fibonacci sequence is used because as the numbers get larger, the difference between them is more visible. If you introduce a 4, how long will it be before you start introducing 6, 7, 9, 10 ...?

These are just estimates based upon the information they have at the time of the estimate. It is used by the Developers to help decide if they have enough work for a Sprint.  They really have no true value past that point.  After the Sprint begins, all of those numbers are meaningless because you are gaining new knowledge about the work. 

What my teams have done in the past is verbally say "It's a big 3 or small 5" and they would pick one.  


09:22 pm January 20, 2023

As Ian and Daniel mentioned, the team can use any estimation approach that makes sense for them. No rules for this.

Some things to consider...

If you were not using numbers, and were using sizes instead, would you have the same concern? If you thought it was bigger than a medium, would a large seem too big? Or would you just go with the large? Don't overthink it too much just because you are using numbers.

Being presented with too many choices could actually make it more difficult to select one. Are you familiar with the jam study? Customers were more likely to purchase jam when they were presented with fewer options. Similar to this, Teams may get hung up on and loose time to selecting the "right" option when presented with too many of them. It implies a need for precision and precision isn't the name of the game when it comes to sizing. 

Here is a fun exercise to try. Extract cycle time and estimation data for your completed backlog items. Plot this data out in a scatter plot graph. I have done this with dozens of projects using years worth of data and the result is always similar. There is very little actual precision or consistency. What you will find is variation.


04:16 pm January 24, 2023

Take a look at this:

https://www.scrum.org/resources/blog/story-points-are-not-problem-velocity

You may be counting the number of grains of sand in a cup to see the cup's volume.  Too much granularity.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.