That’s how Story Points were sold. But they constantly fail on that.

Why?
– People are bad at estimating and no amount of training and experience changes that. And even if they were good at that for one single task, they would still fail on taking interdependencies, and other ‘systemic’ issues into account.
– Using an averaged velocity for forecasting, which is the only option you have, sets you up to fail on average (i.e. in 50% of all cases). One reason for that is, that averages assume normally distributed data; yet real world processes produce normally distributed data just by accident.

Even if Story Points cannot be transformed into hours using whatever (deterministic) math formula, wouldn’t you at least expect that twice the Points roughly indicates twice the amount of time to do it across many items? Did you ever check whether that is actually true? I did. And found this to not be true in all of the 2 dozen teams I looked at (even over time periods of years). Or, phrased otherwise, I found not a single one where the correlation coefficient between estimated Story Points and duration from Start to Finish (aka Cycle-Time) was high.

Regarding the “even sizing”: Given that, in knowledge work, we’re facing flow efficiencies around 5-15%, the ‘size’ (in terms of effort) of an item does not have a high impact. Which is one of the reasons, why “make them roughly equal” is sufficient. It hardly matters if a item is a 3, 5 or 8 (even under the assumption that people are good at estimating). In addition, when using historical data, you have 3’s, 5’s and 8’s already in there; so the only assumption when using MCS is, that the near future will be similar to the recent past – which is a reasonable one in by far most cases.

So I am not sure why you always seem to criticize them so much, like at the beginning of this article: “especially if you’ve been stuck estimating your work using story points (or hours) for quite some time.” And again points and hours should not be equated…

Stimulating articles otherwise.

Eduardo,

I’m curious how things turned out. Let me know how it’s going 😊

Hey Aleksei,

Before deciding how to handle defects, you need to get clear on what you’re trying to improve. Is the goal to reduce defect rates? To apply WIP limits and stay within them? Or to build a better prioritization mechanism?

That clarity matters.

If improving defects is not the focus, then there’s no need to create cards. There’s little value in tracking something you don’t intend to act on.

But if reducing defects is the goal, then start tracking them. Create the cards and define how you’ll handle them.

Is this defect important right now? If not, move it to the backlog.
If it is, connect it to the parent item and place it at the top of your To Do list. It becomes the priority, and as it moves through the process, it goes first.

Set clear rules to bring visibility and keep improving the flow.

In short, it feels like unnecessary bureaucracy and a mess in terms of process rules.
That said, I can understand the idea of creating defect cards on a separate board just for tracking purposes — but all the actual work should still be done on the main board.

Hi Max,

Definitely a good reminder! We haven’t yet but it’s still on our radar. I’ll make sure to share the results once we do. Appreciate your interest!

Hi Sonya, have you by any chance done that analysis again? Would be extremely interesting to read about the results

In the meantime, I’ve looked at this for more than 2 dozen teams and teams-of-teams. And I didn’t find just one with a high correlation. From that I conclude that it’s unlikely to be a matter of proficiency in estimating.

In contrast to a lack of correlation between Cycle-Time and estimated SP, Velocity – i.e. Throughput measured in SP – and Throughput measured in work items per time typically highly correlate; I found just one counterexample. From that I conclude that if estimation is done for reasons of capacity – i.e. answering the question “How much can be done until X?” – counting work items is equally effective, but more efficient.

Well, nothing new for the Kanban Community, but it’s good to see that being backed up by real-world evidence.