Let me preface this post by saying this: I get Story Points, I
understand how they work, how they should be used and the problem that
they are purported to solve.
Q: So what's the problem? A: Detailed estimates are always wrong. Will always be wrong and can never be accurate except by pure luck.
Q: Why are detailed estimates always wrong?A: Because the real world is a complicated place and it's impossible to see clearly into the future.
Story points answer this by doing something important, they abstract the estimate and allow us to estimate with a larger unit of measurement therefore granting us the freedom to estimate with a lower level of precision.
But the abstraction introduces a new problem. Allow me to illustrate with a couple questions.
- Why do you estimate?
- What is the problem with misestimating your work?
- What is the most concrete and important constraint of a sprint?
- You estimate so that the team has a realistic amount of work in a sprint.
- Misestimation of a sprint is a problem because the team will not have enough time to finish the sprint backlog if they overcommit due to poor estimates.
- The most concrete and important constraint of a sprint is time (unless you have a tool that can stop or slow time, in which case I want in on the beta).
Now in some cases this is a good thing, it's a bit like Mom mashing some cauliflower into the mashed potatoes so we'll eat some real vegetables but I don't see it as something to default to or even a permanent solution to the estimates problem.
So what's the real solution? Combine the best of both worlds.
Estimating in logical time boxes.
Instead of estimating in units of measurements, we estimate in predetermined timeboxes.
A slight tweak should only take a couple of minutes? That falls into the 1 hour timebox. A bugfix should take me the better part of a day? That'll fall into the 1 day time box. What time boxes should your team use? Probably not fibonacci numbers since they'll imply some level of precision which shouldn't be there and tshirt sizes are missing the point of estimating in time as well. The answer is that you should decide with your team but, here are some good ones to start with:
- 1 hour
- 4 hours
- 1 day
- 2 days
- 3 days
- 5 days
- 2 weeks
So what've we learned? A lot actually.
- Detailed estimates are dumb and we shouldn't do them.
- Story Points mask the point of estimating and can potentially sow the seeds of confusion.
- Estimating with time units isn't that different than estimating with story points since you'll still estimate with distinct values rather than detailed units.