To commit or not commit - that's the questions here

Background

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.   

"However, enough work is planned during the Sprint Planning Meeting for the Development Team to forecast what it believes it can do in the upcoming Sprint"

"In this part, the Development Team works to forecast the functionality that will be developed during the Sprint"

Having read many posts titled like "The sprint commitment is dead", "We don't need a sprint commitment" this post explains my current way of thinking about it (to be honest I prepared writing about the sprint commitment - but let's move forward and transform it to the sprint forecast). 

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

What supports to have the forecast in a realistic way that really supports its purposes?

• 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

For the Scrum Master it's important to know the maturity level of the team to know how much to guide the team towards the sprint forecast. As a Scrum Master you ensure that the right questions are raised in the right moment. You can influence the sprint outcome with your guidance - either heavily or lightweight.

Consider e.g. the situational leadership model (also nicely describe in shades of Scrum - the Scrum Master role).

Healthy or unhealthy signs

Healthy

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

Unhealthy

• 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 changed?

I like the idea to name it sprint forecast and not longer sprint commitment. This way it's more oriented on reality, that a sprint is still affected by changes and the word forecast anticipates changes. It removes focus from the misleading usage in the past. 

My answer to the blog title: Let's use the sprint forecast to foster having committed teams delivering the best possible result.

What's your opinion

Until now there are not that many comments and discussion in this blog, although you visit it? Can you help me there ... should I change something? In this post? Do you have a different opinion or enhancements?

Thanks for your replies ;-)

Further readings

• http://blog.risingtideharbor.com/2011/06/team-commitment.html
• http://www.andrewfuqua.com/2012/10/sprint-commitments-are-amortized-death.html
• http://yuvalyeret.com/2011/10/13/scrum-sprint-commitment-rant/
• http://yuvalyeret.com/2012/06/30/the-scrum-sprint-commitmentforecast-as-an-expectation/
• http://www.jonarcher.com/2010/10/commitment-what-can-we-really-commit-to.html
• http://www.jonarcher.com/2010/10/commitment-what-can-we-really-commit-to.html
• http://www.infoq.com/minibooks/real-life-scrum

     Download MindMap (for use with Freeplane)