When I teach agile fundamentals classes, I frequently emphasize the importance of inspection and adaptation. Teams which don’t use feedback loops with their products and their processes should not consider themselves to be very agile.
For those teams which use an iteration-based cadence for their delivery such as those who have implemented the Scrum framework there have multiple feedback loops to help them improve. A common example is comparing how many product backlog items they were able to successfully complete during an iteration with how many they had forecast that they would be able to complete at the beginning of the iteration.
For stable teams using fixed duration iterations, a reasonable assumption is that over time the volume of work which they can complete should become progressively more predictable which in turn should improve forecasting.
So what happens when a team consistently misses their iteration forecasts by a significant margin?
If it is a team which regularly completes more work than was forecast, this could be the result of traditional management oversight causing team members to act very cautiously when estimating their work. Letting the team know that it is normal that they might miss their iteration forecasts on occasion and spending effort on making the team feel safe might help them to start making more aggressive forecasts over time.
But what about the team who is frequently completing a lot less than they had forecast?
It would be very easy to write off such teams as undisciplined or immature but such judgments won’t help the situation.
There could be many factors causing the team to fall short including:
- Underestimating work item effort or complexity
- Insufficient dependency identification
- Poor risk management
- A lack of focus caused by multitasking or other sources of distraction
A retrospective provides a safe place to identify the situation and to come up with improvement suggestions which the team can take into their next planning session.
This might also provide a good opportunity for the product owner to express some sadness that the team wasn’t able to meet their forecast and to help them understand how this could reduce their credibility in the eyes of key stakeholders.
Regardless of the cause, understanding why the team is over-forecasting is an important step as that information can then be used to create a sense of urgency regarding this behavior.
Easy in theory, difficult in practice 