Estimate Story Points in Ranges
Someone once told me this great analogy for estimating story points.
Image you have a well where you take water, and you need to transport 10 litres of water back to the village. You have a 8 litre bucket and a 13 litre bucket. Which do you use to transport the water?
Its obvious that it is the 13 litre bucket. The 8 litre one is way to small, and even though the 12 litre one is too big, you would use that one. When you think about it; you would use the 13 litre bucket for all amounts of water from 8 litres to 12 litres.
You should think the same way when you are estimating user stories. Each value should be thought of as a bucket, or a range.
When estimating in story points and using the Fibonacci sequence, any estimates you give should be for that number and until the one that is lower. So for example if you do give a user story 13 story points, it takes into consideration work that is from 8 to 13 story points.
Using this approach helps to get the team focused on the estimates being precise, which actually defeats the purpose of estimating. Helping the team, when estimating to think about putting user stories in buckets will help to make the process a bit quicker and relaxed.
Rounding Estimates Up
There might be some concerns with this, and I certainly had them when I first heard of this concept. Wont this just lead to inflating estimates?
In theory this shouldn’t happen.
Imagine you have a user story that is at 10 so you assign it 13 points, and you come to Sprint Planning and its too big. The team might break that down into smaller story points of 5, 5 and 2.
You see now that that totals up to 12 points, which is one less that it was before, but its still 2 points over the original 10 you thought it was. By forcing the estimate into the 13 bucket makes it more likely of estimating the realistic delivery date of the functionality. If you had rounded down to 8 then you would have been 4 story points over (and late).
Work tends to increase when you get down to the more granular detail. Its better to round up and have a more realistic delivery date than round down and risk potentially being late. Rounding up isn’t inflating user stories, its taking into consideration the uncertainty.
Process hacker, optimizer and team motivator. Blogging my ideas, initiatives and innovations. Certified Scrum Master/ Product Owner & Agile Project Manager
Please don’t forget to add or follow me on the following social media!