Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.
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
- 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
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.
Let me know what you think in the comments.
Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.