Did you hear about estimating stories in story points with Fibonacci? Yeah, it may sound fancy, but it is a nightmare in implementations that I saw like you use 1, 2, 3, 5, 8,1 3, and 21 values to estimate your tasks. Then what’s more funny scrum master tends to sum up them and calculate the average per sprint/per quarter! Like you have no relative scale and you’re trying to do an average that requires values to be relative to each other. For example if you have one task estimated as 3 story points and three tasks for 1 story points it’s usually like task for 3 story points takes much more time than those three smaller ones together.
I think it is sometimes proposed and forced by non-tech scrum masters, because they think it needs to be that way. It annoys me. It does not have to be like that.
I really prefer to have a linear scale (with step 1), like:
- 1 story point – around 1 day of development
- 2 story points – around 2 days of development
- 3 story points – around 3 days of development
- 4 story points – around 4 days of development
etc. In that way you can really see how much work will fit into sprit.
Do not estimate bugs
Sometimes I hear do not estimate bugs – and I always think WTF? Without estimating bugs you’re not able to asses how many of them you are able to take into sprint. Something different is to fix bug that wrong image is shown and something different is to track why wrong price is calculated at the end of quarter. So it should be visible, how much do you expect them to differ. In my opinion esimating bugs is just fine
Average story points per sprint
With usage of story points constrained to values from fibonacci sequence you cannot do regular maths on that numbers. Why? Because they are not proportional. So using arithmetic mean will not give you reliable results. Probably you heard many times why this time we planned sprint using artiehmetic mean from pasts sprints and we still did not deliver all stories. Sounds familiar?