Following the Scrum guide the sprint commitment is now transformed into the sprint forecast – and again my previous way of thinking about the commitment evolves.
Purpose of the sprint forecast
- Orientation and sprint focus – combined with the sprint goal the scrum team knows what it planned to deliver until the end of the sprint. In addition to the sprint goal as a nice sprint frame described in a more generous way, the sprint forecast pins it to concrete stories to implement.
During sprint planning all agree on the forecast – it implies a common understanding including steps of adjusting and reaction – it creates visibility for everyone involved.
- Information for other teams – it enables a sprint visibility as it shows what’s planned for the next product increment. Teams dependent on it can anticipate their next steps (although it’s still only a forecast!).
- Input for the release forecast – the product owner can use the sprint forecast to update the release plan. It’s an early outlook that enables already necessary adjustments. As it is a forecast – it needs to be handled carefully.
The forecast fosters
- Having a committed team – as the Scrum team planned together what it wants to deliver and having a common picture helps being focussed.
- Inspect and adapt – During the sprint to see if you’re on track or adjustment is necessary. At the end of a sprint as input for your retrospective. What did you plan originally and compare it to the sprint result. Are there impediments to remove? What changed? The forecast sets the expectations necessary for learning.
Sprint forecast enhancer
- Regular backlog grooming to get a common understanding about the functionality meant by a story. A clear understanding enables a higher quality forecast.
- Use yesterdays weather (past experienced velocity) and the sprint capacity as anker points. This gives you a reference and helps to avoid over pacing and fosters raising questions from the team, if the forecast is far away from the past velocity. Some examples for possible influences are:
- it’s something new to implement
- the understanding of what to implement is not yet given
- did we consider slack time (sickness, education, vacation) properly?
- Using smaller stories as this allows a more fine grained forecast. The bigger the stories the more blurry it is and the more uncertainty comes along. With smaller stories the chances to deliver parts at the end of the sprint is higher – but this is an own post.
- Measure differences of your sprint forecast and sprint results. We use a so called sprint ending session (a scrum team internal closing of the sprint – to see what is finished, what remains and doing a cleanup) to finally see for every story what was the original estimation and whats the result. For huge differences we collect points to discuss in the retrospective but at least ensure a common team understanding that there was a difference.
- Adress huge sprint forecast and sprint result differences regularly in the retrospective. To learn from the past and try to bring the forecast and reality more together (if feasible).
- It the team’s forecast – avoid pressure from management or even the PO or ScrumMaster on the forecast. It’s not about tuning the forecast but getting an good overview about what can be delivered during the sprint. The team creates the forecast – no one else.
- Trust – as this enables that questions are raised and to experiment with the limits and setting sportive rather then defensive forecasts. For trust you need to ensure a trustworthy environment (read The Five Dysfunctions of a Team: A Leadership Fable (J-B Lencioni Series to get more input about the importance of trust)
Consider your teams maturity level
Healthy or unhealthy signs
- The team uses the forecast to learn and improve its capacity steadily. You discover process improvements.
- The team stretches a little beyond your comfort zone without over pacing.
- The forecast is used for punishment and blaming games. It’s guaranteed that the outcome are better forecasts – but at the price of lower trust, low level forecasts or other gamings.
- The team ignores the sprint forecast – it’s not used throughout the sprint, especially not in your retrospective. It doesn’t matter why a forecast had a huge difference to the sprint result.
- Focus on forecast. Don’t tune to much on this area and try to use it for it’s described purpose. It’s one Scrum element – that needs to be combined with the others – like the Sprint Goal, embedded in your Daily Scrum, Retro, Sprint review.
What’s your opinion