Why aren’t story points a unit of time?
Continuing on the theme of estimation, a common question that comes up is “so are story points a unit of time?”, usually followed a few seconds later by “Why not?”. People seem to want the abstract “story points” to become hours, days, or similar. The consensus in the Agile community, which I agree with (though I don’t think estimation is very valuable in the first place), is that no, story points are not a unit of time. Don’t try to make them become one, tempting though it is.
Why not make them a measure of time?
The short answer is “because that’s not what they are”. The more complex answer (if people don’t accept that one) can best be explained using this analogy.
Imagine there are two runners, and every day they both run the same running track. You are thinking of trying out that running track, but unsure if your stamina will be up to it. Which is a better question – “how long” (i.e. how many kilometres) “is the track?”. Or, “how long (in time) does it take you to run the track?”.
The former is obviously a better question; it tells you how much effort there is in running the track. If you ask the second question, you might get two wildly different answers, that tell you more about the runner than the track. For example, the first person might be quite unfit and say “it takes an hour”, and the second might be training for the Olympics and say “it takes 15 minutes”. Which is right? Both. Yet the answers are completely different.
That is because you asked “how much time does it take YOU to run the track?”. If you ask how long the track is, you will get an idea of the objective difficulty of the track, which will inform your decision about whether to attempt it or not, i.e. how difficult it will be (for you, for your friend who is also thinking about trying it, and so on).
So what if you get different answers?
You might be thinking “so what if I get different answers? One of the developers in my group is a gun and can get it done in one day, the other is a newbie and would take five days, so I’ll just give it to the gun and call it a one-day user story”. This is lazy thinking and will lead to two problems.
The first problem is that the estimate needs to be agreed on by the whole group since it is an estimate of the whole team effort to get it from Sprint Backlog to Done. So you won’t end up with a “one-day” user story, you’ll have a bunch of pointless arguing over whether it is a one-day or a five-day story. The second problem is that it might not get done by the “gun” developer, it might go to the other developer (or maybe somebody else altogether).
But a user story will get done by someone at some point, right?
You might be thinking “but it has to go to somebody at some point, so why not get one developer to estimate it in days and get that person to do it?”. This seems plausible, but things can change. People can go on leave, they can leave and join teams, stories can be bumped around in priority. It’s better to not make any assumptions about who will be doing what.
Also, moving a story is not just about programming work, there could be tasks around UX, testing, accessibility, security, and so on. How do those factors come into it? You can try and get time estimates for each of those parts, which strangely is what a lot of people do when they break stories into tasks. I don’t really like doing this.
Don’t people break stories into tasks and put time estimates on them?
A common practice is for teams to break a story into tasks and put time estimates on each task (you don’t need to do planning poker or anything, each person puts their own time estimate on their own task). This is a reasonable thing to do, as long as people don’t try to “back out” the time estimate for the story by going backward from time estimates on tasks up to the story point estimate on the story. Remember, you’re not trying to discover “how long will this story take?”. You’re trying to find out “how hard is this story compared to other stories?”. And the only real value in doing that is so you can forecast how many stories of similar difficulty you can do in a similar time period.
