What is story point estimation anyway?
If you’ve read the last post I wrote and are scratching your head as to what all this ‘points’ and ‘velocity’ stuff is, this article is a quick primer on what is story point estimation. I’ll explain what it is, how it is usually done, and why we are supposed to do it. I’ll also discuss how valuable I think it is.
What is story point estimation?
Story point estimation is an agile practice where a team (e.g. a scrum) assigns “points” to user stories, before work begins on them, to describe the difficulty of completing those stories. As the team completes stories, the points assigned to those stories are “earned” by the team for that sprint. So if a team estimates ten stories at three points each, and the team completes half of those stories in a sprint, they have “earned” 15 points that sprint (five stories at three points each). These earned points per sprint become a team’s “velocity”. If a team has high velocity, they are completing a lot of stories per sprint.
Where did it come from?
It is not part of the official scrum canon and is not in the official scrum guide. Really. Go read it if you don’t believe me. It’s hard to pin down exactly where it started, but it was probably most clearly explained in Mike Cohn’s influential book from 2005, “Agile Estimating and Planning”.
How does it work?
The idea is that the team collectively decides on a number (it’s just a number, it’s not a measurement of anything) that represents the complexity and difficulty of delivering that story. The number is for the whole team to deliver the whole story, end to end, from Backlog to Done. The actual numbers are just an indication of the relative size of the stories compared to other stories. So a ‘1’ point story is just that: a ‘1’ point story. The ‘1’ doesn’t mean anything by itself. It is, however, half as big a ‘2’ story, one third the size of a ‘3’ story, and so on. They are not a measurement of people, days, hours, or anything like that. The numbers are usually arrived at via planning poker.
What is planning poker?
Planning Poker is a technique popular in the agile community for arriving at story points. (Although it is not part of the offical Scrum guide). The team gathers around and each person has a set of cards (like poker cards), with Fibonacci numbers on them (this is a sequence of numbers that goes 1, 2, 3, 5, 8, 13, 21 – each number is the sum of the two previous numbers). The team chooses and discusses a story. Then each person secretly chooses one of their poker cards that they think best describes the “size” of the story, and everyone simultaneously reveals their cards.
If they are all the same, great, that’s the estimate. If they are not, then the group has a discussion about what why they feel it is that size. You can then come to an agreement on the final estimate (I recommend this), or do the poker estimation again until everyone comes up with the same number (I don’t recommend this).
Planning poker might sound like fun but it can get old quickly. I have written about some alternatives to Planning Poker.
Why choose the estimates secretly?
It might seem odd that each person chooses their estimate secretly and then everyone reveals theirs at once. The idea is we want to get each person’s honest opinion, without groupthink or people being herded into a particular estimate. If each person revealed their estimate in turn, people could become influenced by what other people had chosen or said. If each person chooses secretly and they all reveal their estimates at once, you get an unbiased show of each person’s estimate.
Why use Fibonacci numbers?
We use Fibonacci numbers because the greater the size of a piece of work, the more uncertainty there is around the size of that work. And if there is a lot of uncertainty, the estimate normalisation should change to reflect that. The Fibonacci sequence enforces this scaling of uncertainty by its exponential growth. Discussing whether a story is 16 or 17 times the size of another story is pointless; discussing whether it is 2 or 3 times the size of another story is fine.
Why do it at all?
Good question! I think it is a practice that has some but very limited value. I am basically against estimates. Or more specifically, I don’t think teams should spend any more than a minimum of time on estimation. Long planning poker sessions are torturous (it is a lot less fun that it sounds, trust me), and provide little value.I’ve written elsewhere about the folly of estimating costs over benefits.
Question time!
Have you done story point estimation in agile software teams? Did you find it to be useful or pointless or somewhere in between?
