The case against per-story estimates

Hot take (that may lead to some “interesting” conversations when I get back from sabbatical): Points or other detailed project estimates in software project management are a waste of time.

My own experience is that I’ve seen many teams spend lots of time on points or other estimation schemes. I consider that process broken. I’ve rarely seen those estimates be of sufficient quality to justify the time spent making them.

There are too many surprises (sprint injections, unanticipated dependencies, bugs found along the way, etc.) to make those estimates meaningful in real-world experience.

This article, from somebody who professionally coaches teams on their agile processes, brings the receipts.

Key quotes:

When we analyse the data, there is never a correlation between the estimate and the actual time it takes to get the work done.

The chart below (not included in my excerpt) is typical of a development team. Estimates on the Y axis and the actual cycletime on the X axis. We can clearly see that there is no correlation between the two. Items estimated at two story points are taking anywhere from two to nine days.

I graph this data with every single team I coach and I have never seen a strong correlation from any of those teams. If you’re convinced that your team is different then I encourage you to graph your own data.

I agree with the closing sentiment:

To be clear, I’m not suggesting even for a moment that you shouldn’t talk about the story. I’m saying that putting a number on it is a waste of everyone’s time.

Mike Bowler at Improving Flow blog: Per-story estimates

(Also, I see they’re fans of kanban, which I am also. But we’ll save that discussion for another day.)