pdurlej blog

Every wannabe agile organisation tries a different approach to estimating using Story Points, which is the standard way to measure work in Scrum. It is hard to start, and after few sprints, teams tend to go back to estimate in hours, even as estimating in Story Points gives more value for the team in the long run. Additionally, this „Story Points” are confusing for external or internal stakeholders, as non-agile people usually estimate effort through hours.

So the first step for confused developers, managers and customers should be linking Story Points and hours in some way, so this measurement is valuable for Scrum team and comfortable for all sides. To achieve that I tend to explain that Story Points are a series of ranges of the probabilities of delivering task in a given amount of time (see the table). It seems to work, so I decided to write it down. You can use it for teams that start working in Scrum, but it might be beneficial for every organisation which earns money by selling hours of developers work.

---

Humans & estimating

Humans sucks at estimations using abstract values, example: how much grams does this apple weight?

We are much better in comparisons between objects or events, example: is this apple is bigger or smaller than orange?

More obvious the differences the easier is us to decide which option is closer to the „truth”, example: are oranges looks more like mandarines or an apple?

This is why values like Story Points, with big differences between each levels are better tool for estimating than hours.

Exponential complexity

The less you know, the (much) bigger is unknown of possible fuckups.

Complexity of task, and time needed to finish it, tend to it grows exponentially not linearly.

We need to perceive SP and effort like a category on their own.

Values of estimations

This is why Fibonacci-like sequence are so popular as, they aren’t linear which helps our brains to treat it diffrently.

The smaller scope of the task, less SP, the smaller effort variation between other tasks estimated in the same value will be.

I found SP values of 1, 2, 3, 5, 8, 13, 21 – as the most useful for every day work in weekly or bi-weekly Scrum sprints.

Real life anchors

No issue which take less than 15 minutes to do should be need to be written.

Even simplest tasks worth writing, tend to take around one hour. This is my lowest anchor, and I give this type of tasks 1 SP.

The biggest issue which should be in the sprint scope should be possible to finish in one week sprint. This means it should take around 40h. So for this type of tasks I set 13 SP.

For bi-week sprint the time we have is 80h, so I set this to be 21 SP type of task

Story Points values	„Linear” time	„Exponential” time	„Average” time	Real life anchor
1	0.25h (15 min)	1h	0.625h (38 min)	„Less than an hour”
2	1h	3h	2h	„A few hours”
3	3h	6h	4h	„Bigger part of the day”
5	6h	12h	9h	„Around a day”
8	12h	24h	18h	„Two-three days”
13	24h	48h	36h	„Around a working week”
21	48h	96h	72h	„Around two weeks”

Tips & tricks for the future

It will never be a perfect way to predict the future.

Avoid 13 & 21. Try splitting them, as the smaller issue is the lower uncertainty you will have.

With time this time ranges will evolve, and this is healthy! Feel free to adjust them after your team knows themselves better.

Developers should be challenged and accounted for their estimations. Let them learn on their mistakes – this is the most crucial part for creating self-improving teams.

Be careful into creating more detailed estimation ranges, as they make the whole process longer, and more stressful for developers while providing just illusion of better control for management.

As a manager, deciding where between „Linear” and „Exponential” hours on average tasks will be is your way to take into account project risks.

If you are clueless, assume that team will be around „Exponential” value, as planning fallacy makes us underestimate approximately 60% of total time needed for finishing complex task.