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.

Hi Yunbo,

There is nothing fancy behind the scene. Please check the “What is Monte Carlo simulation?” section to see how we implemented it.

Can you tell which bayesian model is used behind the scene ? or how do you calculate the probability distribution statistically ?

Thanks

Clear, thanks a lot for the quick responses!

It’s up to you to decide which percentile to choose.

How much risk are you willing to live with? If the work is easy, you’ve done this before, your workflow is stable and predictable and you don’t expect any issues along the way, go with the 70th percentile.

If there are plenty of unknowns, it’s something you haven’t done before, the nature of the work is complex, go with the 98th percentile.

And don’t forget to reevaluate your forecast on a regular basis to make sure you stay on schedule.

So we should look for the date indicated by the 85th percentile, that is the date in the normal distribution that has 85% of simulation outcomes below it, correct?

Hi Chris,

Yes, that’s exactly right

However, don’t assume that’s the most probable date. Look into the probability it comes with to understand what’s the chance of hitting that target.

Thank you, Wojciech!

Please, don’t exclude non-working days from your forecasts. If the end date falls on a non-working date, go with the first working day next week.