Should Your Dev Team Stop Using Story Points?

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.

Here's the thing, I'm a minimalist at heart. My first (and typically second and third inclination) whenever I learn something new is to strip it down to it's minimal working moving parts (there's an acronym in there somewhere). With story points it seems that the industry has reached a solution without fully understanding the problem.

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?

Since blogging is a bit of a one way conversation until it's published let me fill in some of your answers.

• 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).

So when we look at it objectively, we're actually fooling ourselves by pretending we're not estimating with real time units.

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

At some threshold with these you'll want to decide to split the backlog item into more manageable chunks and you'll want to estimate with the assumption of one person working on an item from beginning to end. In practice there may be multiple hands on that item at any given time but we want to capture total time expended not calendar dates in progress.

So what've we learned? A lot actually.

1. Detailed estimates are dumb and we shouldn't do them.
2. Story Points mask the point of estimating and can potentially sow the seeds of confusion.
3. 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.

Let me know what you think in the comments.