[dirklectisch]

Author of the article here.

Unit of work is explicitly vague because it refers to the units you are using in your project, be it user story, requirement, epic, bug etc.

You do not need to know the size of each unit. In fact the method I describe acknowledges that there is variance in the size of each unit.

Some people advocate "same sizing" units of work. I have always thought that was a weird idea because it would imply making small units bigger. How would you make the unit that describes changing the color on a button the same size as integrating with an API? You can't even if you would have perfect knowledge of the amount of work required.

[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.

[monoideism]

So what happens in your method when you hit a major unforeseen issue, as frequently happens in a project? If your prior 2 projects went by without a problem, then you'll still be sitting on a bad estimate.

Yes, after time, this should start to even out with your method, but who keeps the same team or even stays in the same job for more than 3-4 major projects? It's fairly unusual these days. Yes, I know there are some senior devs that stay at the same job for 5 or even 10 years, but their team, and even the company's hiring standards, are likely to chance significantly during that time.

That said, it is an intriguing idea, and one that bears more study. I'm not yet convinced but I may try it out.