This model is working to identify the Inspection Paradox [0] - most time is spent on doing tasks that take a long time to do. Combine that with high variance, and one task will blow out and a project will be spent working on something that is much harder than people thought, and that the estimate process didn't see coming.
My interpretation here is software engineers are better at estimating tasks than I thought. The next step is analysing tasks being performed in serial to show how many sub-tasks a project can have before the estimates are effectively meaningless / likely to blow out an unpredictable amount. I bet it turns out to be about a sprint's worth of work. Real people have a knack for feeling out those sort of tipping points empirically.
My interpretation here is software engineers are better at estimating tasks than I thought. The next step is analysing tasks being performed in serial to show how many sub-tasks a project can have before the estimates are effectively meaningless / likely to blow out an unpredictable amount. I bet it turns out to be about a sprint's worth of work. Real people have a knack for feeling out those sort of tipping points empirically.
[0] https://en.wikipedia.org/wiki/Inspection_paradox#Inspection_...