[lordlic]

From TFA:

> Throughput is the amount of work that comes out of your project by unit of time. It’s up to you to decide what units make sense for your context. Days, weeks, sprints, stories, bugs, epics – anything goes as long as you’re consistent.

Using days/weeks/sprints as your unit of work for determining throughput seems circular. If you want to know how many weeks of work your team can produce per week then you don't need a monte carlo simulation to tell you that.

Using stories/bugs/epics is flawed too, I think. You can have a fantastic model for your team's throughput in stories per week, but that doesn't tell you anything about when the project is going to be done unless you know how many stories there will be. There are two variables here (throughput and quantity) and you can't get useful information out of the product of them for free.

To see why, imagine that you take only the minimum amount of effort to very roughly divide the project into sensible-seeming chunks. In that case, your throughput in chunks per week will be meaningless (i.e. your model will have a confidence window which is uselessly wide) because the chunk division will have barely any relationship at all to the amount of actual work in each chunk. Now imagine that you're a bit more diligent in your project planning and look in a bit more detail at the work that will be involved. You've done some work to clarify what code will need to be written, and your confidence window will narrow accordingly. Now imagine that you're even more diligent. And so on, and so on. You eventually end up with zero error in your model, but in the process you've completely determined what code will need to be written, and the project is finished! Congratulations, you've invented waterfall. There's no free lunch here as the intro paragraphs of the blog post promise.

I assume that in practice you're stopping at some point in the middle of the extremes of doing nothing and planning out every line of code, and then applying your statistical model at that point, but I think you'll still be thwarted by the (at that point) partial disconnect between the chunk divisions and the actual amount of work in each chunk. We've all experienced innocent-seeming tasks that end up consuming vast amounts of time unexpectedly, and various degrees of this phenomenon is what fundamentally ties the amount of error in any pure "stories per week" model to the amount of effort you spend planning and estimating the stories. No free lunch.

[monoideism]

Exactly. I read the article fairly carefully, but the logic seemed circular to me. For a novel project, the problem of how to divide it up into predictable units of work remains. It's always the black swan little subprojects that destroy an estimate, and this approach doesn't help with those unforeseen events. If I could avoid those that reliably, I'd be able to estimate projects with a high degree of accuracy, even without using this approach.

In my experience, only increased subject matter expertise and a solid team with lots of experience can minimize the black swan events, and even then not 100%. They still happen with disheartening frequency.

And as you say, it doesn't buy you much if you want to measure how much work your team does per day/week/month, either, for the reasons you describe.