In my previous blog post 'The 9 Smells of an Organization' I described the difference between the terms commitment and forecast. This resulted in an intriguing discussion that triggered me to elaborate some more on this topic and share the highlights of this conversation.
The Misuse of Commitment
Commitment might be the most abused term in Scrum. It's related to the famous saying "we ask them for estimates and then treat them as deadlines". In organizations starting with Scrum, some old school (project) managers fear the seeming lack of grip that comes along with it. But luckily the Scrum Guide offered them 'commitment'. Development teams should commit themselves upfront to sprint results. No matter how complex (and by this unpredictable) the software, a hard commitment by the development team is a precondition. Should any unforeseen problems arise, then that's the problem of the development team, they gave their commitment, so they should fix it, just order some pizza and carry on!
To me, commitment in this context smells. Therefore I prefer using the term 'forecast'. When planning a sprint, the team gives a forecast of the amount of functionality they think they can deliver, given the available knowledge. But taking into account the complexity of software development, giving 100% guarantees and impossible and meaningless. I rather trust teams they will do everything that's possible to deliver a valuable, high-quality product.
Fortunately, in the latest Scrum Guide commitment was actually replaced by forecast, I can only warmly welcome this.
What Commitment is About
The discussion I've had basically boils down to: if I can't ask a commitment of the development team, how will I know they will actually deliver the discussed scope of the sprint? The short answer is: you don't. People can get ill, new insights on a technical approach might occur or some upfront dependencies turn out to be real impediments.
The misunderstanding is the perception that by changing commitment in the forecast, the development team doesn't have to commit to anything anymore. But the only thing that changed is the development team now gives a forecast of the specific product backlog items they think can be completed in a sprint, this instead of giving a commitment to the exact scope.
However, the development team still does commit to:
- Delivering high-quality products. The team commits to doing their best to achieve the goal while maintaining high quality.
- Meeting the sprint goal (instead of the exact amount of product backlog items)
- Delivering working, usable software that meets the expectations of the customers and users
- Working only on the product backlog items with the highest value
- Focus on continuous improvement, technical excellence
- Truly collaborate with all the business people involved
And for sure, I prefer a development team that commits to all the above points, then a team that drops quality and takes some ugly shortcuts only to "satisfy" the stakeholders with a "done" sprint. When this is a reality, you've got a lot of smells in place that need attention, and to complete the circle: read my previous blog post :)