dirklectisch

Author of the article here.

Significant changes will indeed make your forecast not come true. But mostly people are not asking to predict for situations with significant changes.

Incremental changes will just be incorporated in the forecasts over time. The forecast continually adjusts to new information becoming available.

It's interesting to know that after about ten work items completed the number become pretty stable. So it's easy to reset or adjust the forecast in case of a big change in the team.

I was personally surprised to learn how stable the output of a team is if its composition doesn't change. Tools have some impact on productivity but so big that you have to throw away your predictions. No one is complaining anyway if you over deliver a little.

Author of the article here.

There are situations that are way more predictable than the stock market. We as humans use the past to successfully predict the future all the time. For example we predict that we won't be able to walk through walls not because we understand how atoms bounce off each other but because we experienced not being able to do that.

Software Development is certainly more predictable than the stock market but less predictable than the walking through walls example.

In a stable team, often past performance is a strong indicator of what will happen next. It's not perfect, black swans can occur, but no one is asked to predict if your project will get cancelled for example.

Author of the article here.

I agree with this response. We are normally not asked to predict for situations where something big changes in the team. But I of course acknowledge that these things do happen. When you have a stable team, the numbers that this method yields are also very stable.

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.

Author of the article here.

The thinking here was that work that reaches a cycle time that is higher than 85% of the other work we completed is probably worth some extra attention. Is the person working on it stuck? Is the problem so complex that it might be useful to sit down and have a look at it together?

We all felt it was a good motivator to work together on a regular basis. Or at least step up the amount of communication around that unit of work.

Author of the article here.

I normally recommend when starting out to take a small segment of your process first and then widen it as you get more experience.

For the start point I usually try to think of these aspects:

- Can work still be cancelled at this part of the process. If so it's probably not the right spot to measure the start date.

- Can work still be reprioritized at this point in the process? If so that will significantly widen the precision of the predictions that the forecast will make.

Also note that setting a the start date at the moment of commitment still gives you valuable insights in how much work you will be a able to next.

For setting the end date I think when the software is released is the most interesting point to measure. As always it depends on context. If you do a yearly release this doesn't make any sense because the granularity of all your predictions will be a year.