A regular topic of conversation within my Scrum training courses revolves around commitments and forecasts when using the Scrum framework. Frequently we uncover significant and important misunderstandings about what Scrum Teams can commit to and what they cannot.
The most often talked about example refers to those Product Backlog Items which are taken into a sprint by the developers and which then seems to turn into a hard commitment such that if not all those Product Backlog Items are done then something is wrong and a possible belief that the Scrum Team has failed.
This article is an attempt to help debunk at least this one myth whilst using the Scrum framework to build complex products and an overall recap around commitments versus forecasts in general across some of the evolutions of the Scrum Guide over time.
Let's be clear on what commitment actually means:
A quick online search gives these two definitions for 'commitment':
- "The state or quality of being dedicated to a cause, activity"
- "An engagement or obligation that restricts freedom of action"
These are actually quite different in meaning. The first relates to dedication. "I couldn't fault the team for their commitment". The second relates to a future state that we are promising to achieve, a guarantee, a promise.
Let's now explore some of the key elements around commitments and forecasts from the Scrum Guide as it has evolved over time.
Scrum Guide 2010
- "The Team has committed to a Sprint Goal, and to these Product Backlog items"
Within this first version of the Scrum Guide there is reference to the fact that there is a firm commitment that all items taken into a Sprint are to be done. If not all items selected are done by the end of the Sprint then maybe there has been some kind of issue worth exploring further. Have we therefore failed as a team since we did not achieve all that we promised?
A potentially interesting point around this is the fact that probably a lot of teams currently using Scrum today have never read this original 2010 version but yet still have a strong belief that all items selected must be done or else something has gone wrong. If this has not come about from reading this version then could it be due to the culture and behaviours already inherent within the wider organisation?
Scrum Guide 2011
Thankfully this use of commitment did not stay long and was updated in 2011.
- "...the Development Team forecasts the Product Backlog items it will deliver in the Sprint"
- "...Development Team to forecast what it believes it can do in the upcoming Sprint"
- "...Commit is now forecast"
Early on there was a realisation that when dealing with complexity and significant amounts of unknowns that it is simply not possible to perfectly plan all that is to be done even within the time-box of just one Sprint.
Scrum Guide 2016
The 2016 version introduced us to the Scrum Values and one of these is commitment.
In this regard it means (but not limited to) committing to being professional, committing to quality, committing to helping and supporting each other, committing to working on tough problems, committing to our goals. This touches on both meanings around commitment. Both on the dedication and effort perspective whilst also hooked into the promise of focussing on delivering future goals.
Scrum Guide 2020
The 3 commitments were then added in 2020.
Each of the core 3 artefacts now has a corresponding commitment which all help bring transparency to the artefact they are a commitment for - so for the Increment we have the Definition of Done, for the Product Backlog we have the Product Goal and for the Sprint Backlog we have the Sprint Goal.
Developers adhere to the Definition of Done.....that's completely non-negotiable. That's a firm commitment. A promise.
The Product Goal and Sprint Goal help Scrum Teams focus on current progress towards a future state which serves empiricism. A Scrum Team is committed to working on one Product Goal at a single point in time and either achieving or abandoning that Product Goal before then moving to the next one.
The Sprint Goal is created by the whole Scrum Team during Sprint Planning (note - the whole Scrum Team and not just the Product Owner). The developers are then committing themselves to creating at least one usable increment by the end of each Sprint that achieves that single Sprint Goal. This is their commitment. They are not committing to completing all the Product Backlog Items taken into a Sprint. As the Sprint progresses and as more is learnt about this work then so the Sprint Backlog is emergent. There has to be a level of flexibility that the Sprint Goal provides. The Scrum Guide makes this super clear:
- "...the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it"
The Sprint Goal is the outcome we are after achieving....the Product Backlog Items selected to achieve that Sprint Goal forms the output. Scrum Teams should always look to maximise outcomes and minimise output. The Sprint Goal is their commitment.....the selected items are their forecast.
In summary...
Be clear what you commit to and what instead must be a forecast due to the inherent nature around complex product delivery.
Commit to goals. Commit to doing the best you can at all times. Commit to helping those around you. Commit to building products of the highest quality. Commit to the Definition of Done.
Remember that Product Backlog Items taken into a Sprint are very much a forecast and not a commitment. Forecast longer term plans with the expectation that these will continue to change and evolve as more insights emerge over time.
Ultimately understand and be professional around what you can and cannot make commitments against.
Want to learn more and talk further about commitments and forecasts, professional Scrum or indeed any element of the Scrum Framework? Check out our upcoming courses on our course schedule with b-agile. We offer both public and private courses to fit your needs.