I know that user stories in Scrum are measured with a Modified Fibonacci sequence (
0.5, 1, 2, 3, 5, 8, 13, 20, 40...). Why does Scrum only use Fibonacci numbers to estimate stories?
No Fibonacci Required
While many agile practitioners have embraced a modified or unmodified Fibonacci sequence for story-point estimation, neither story points nor user stories are actually requirements of the Scrum methodology.
Even if you embrace the practice of estimating with story-points and user stories, you can use any relative-sizing tools you want. Some examples I've seen in the field include:
- T-shirt sizes (e.g. S, M, L, XL)
- Traffic lights (green, yellow, red)
- Starbucks drink sizes (demi, short, tall, grande, venti, trenta)
- Simple sequences such as 1-5 or 1-10.
If you decide to use story points, the key is to unmoor the points from time estimates. This helps to avoid anchoring, and hopefully prevents estimates from being used improperly as a productivity-management metric rather than a planning or forecasting tool.
Feel free to use whatever scale works for your team. However, I'd certainly recommend sticking with Mike Cohn's Planning Poker Fibonacci sequence unless you have a strong reason to do otherwise.
One main reason is to not have debates/estimates like: 19,20, 21, 23 Story Points.
In agile estimation is usually about comparing relative size, it's clear that 1 Story Point is significantly smaller than 10 Story Points, but 10 SP vs 9 SP is not much different.
You want to make sure that bigger numbers are rough estimates and you're not sending to your stakeholders message that you know exactly how big item is.
BTW: That's the reason you have 20 instead of 21 which is valid Fibonnaci sequence number.
The Fibonacci series also better represents the fact that uncertainty grows proportionally with the size of the story. The differences between 1, 2 and 3 point stories are probably better understood than the differences between a 20 and a 40. This is reflected in the distance between story sizes.