Why use Story Points?
They allow team members to estimate more quickly and more accurately and spend less time estimating versus doing the actual work. Plus, they also allow team members with different skill and experience levels, to agree on a single estimate.
What is a Story Point?
A Story Point is a relative abstract measurement of the effort to do something. But it doesn’t just work for software backlog items, they can be used to describe the effort for pretty much anything.
Abstract. They aren’t measurable in any objective sense, so you can’t put a product backlog item on scale and weight it, and even if you could, it wouldn’t weigh the same in one team compared to another. You can though weigh a litre of water, it will weight the same in one team compared to another.
If stories are abstract, how do they take on meaning? They take on meaning relative to one another. A two point backlog item will take twice the effort of a one point backlog item, a ten point backlog item will take twice the effort of a five backlog item.
A story point estimate added to one backlog item, is only meaningful in relation to other backlog items. The actual number doesn’t matter, all that matters is the ratio of the numbers, an item that twice the effort can be one and two points, five & ten points, or 432 and 864 points!
Story points exist on a ratio scale, for example weight in another example of a ratio scale.
I weight twice as much as my daughter. So we know all the 2 point backlog items will take about the same amount of effort, and all the four point backlog items will take about twice as long.
Effort is the time it takes to complete the work, story points are about time, which is often not how they’re explained. They have to be, we need to know when we’ll be done or how much we can deliver in a time period.
Story Points vs Time Estimates
As story points are a relative abstract measurement, they can’t just be time as we how often time estimate are used or created.
For example, imagine two runners at the start of a trail, one is a fast super fit runner, the other is casual jogger, overweight and only just started training.
At the start of the trail, the fast runner says this is 10 minute trail, the slow runner says no way this is a 20 minute trail. This is the problem in estimating in time, the fast runner is correct, it’s a 10 minute trail, but the slow runner is also correct that it’s a 20 minute trail.
If you asked the two runners to agree on an estimate, they can’t, or they’ll compromise that it’s a 15 minute trail, but this is the worse thing they can do, as now both estimates are incorrect.
This is exactly what teams do when estimating in time, how many days will this take? But if you have a team of all different levels of skill and experience, all trying to come up with single number of days for one backlog item, what they’ll come up with is likely to be the same result as the two runners, not accurate.
What the two runners should do, is the fast runner says this trail only takes half as long as the trail behind us, and the slow runner can agree. They can't agree on minutes, hours or days, but they can say half as long, twice as long etc..
This is the huge benefit of story points, team members with different skills levels can agree on an estimate. So story points are about time, or a more accurate description is, the effort needed.
Team members cannot agree on the time one backlog item will take to do, but they can agree that a backlog item is twice as big as another backlog item or whatever the relative effort is.
You can think about estimates in time, but you must speak relatively. So the fast runner is thinking 10 minutes and the slow runner is thinking 20 mins, but as long as the fast runner says this trail is twice as long as the last one, the slow runner can agree.
What are the most common issues when using Story Points?
- Teams insist on equating story points to time
- Teams try to create the perfect estimates
- Teams struggle to estimate when there’s a ranges of skills within the team
- Team members say if I do this item its 3 points, but if she does it it’s 10 points.
Things to do to help teams understand Story Points and their thinking
- Read the above
- Ask relative questions, is that twice as big as the last item, or another item, is this the same as this one?
- Triangulating, compare the items together. Take the the items you’re estimating as a 5, then pick a larger one, say an 8 or a 3, and ask if a 5 is right, or the team may then say actually, it’s probably closer to an 8, so let’s change it.
