Use a 4 in the modified fibonacci sequence
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.
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.
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.
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.
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.