Commitment vs. Forecast: A Subtle But Important Change to Scrum
One of the most controversial updates to the 2011 Scrum Guide has been the removal of the term “commit” in favor of “forecast” in regards to the work selected for a Sprint. We used to say that the Development Team commits to which Product Backlog Items it will deliver by the end of the Sprint. Scrum now encourages the Development Team to forecast which Product Backlog Items it will deliver by the end of the Sprint. It may seem to be a simple wording change, but in fact there are strong reasons behind it, and surely it will have great implications.
Why forecast is better suited than commitment?
There’s an immediate reason for the change, which has to do with the meaning of the words themselves. The word commitment usually relates to undertaken duties. After committing to deliver a list of Product Backlog Items, the Scrum Team, foremost the Product Owner and especially the stakeholders may feel that there is an obligation to actually deliver all of them at the end of the Sprint. But reality keeps on showing us that it is difficult, if not impossible, to always fulfill this self-imposed commitment without making compromises to quality. A Sprint Backlog is complex enough that uncertainty is always present, and common sense tells us that we shouldn’t promise what we are not sure to be able to deliver. When we use the word commit, we can be easily biased towards that duty-obligation-promise way of thinking.
On the other hand, the chosen alternative “forecast” has to do with making assumptions based on reliable information and evidence. This is much closer to how an experienced Scrum Team works, where everybody knows that the initially crafted Sprint Backlog - and thus, the associated list of Product Backlog Items - is subject to change as more becomes known throughout the Sprint. The Scrum Team also knows that reaching the end of the Sprint without having done all the initially selected Product Backlog Items sometimes just happens, despite its best efforts. Continuous collaboration between the Development Team and the Product Owner thus leads to renegotiation of the scope of the Sprint Backlog during the Sprint; if we pay attention to the meaning of the words, this would lead us to have a broken commitment versus a non-materialized forecast. When a commitment is broken or not fulfilled, it is usual to expect some sort of accountability, fault, or even compensation. When a forecast doesn’t come true, it is easier to think about matters such as learning from the experience, improvement and - in one word - empiricism, which at the end is what Scrum is about.
Shall you redeem for a failed commitment?
But the most important reason for the change (which is a direct consequence of the former argument), is the misuse, and even abuse, that the word commitment has suffered during lots of so called “Scrum” projects. Typically the situation arises from one –or both- of the following sources: the “business” side of the project (customer, stakeholders or even the Product Owner), or the Development Team itself.
It is not uncommon (or unreasonable, frankly) for people on the business side to hear that the Development Team has committed to deliver a list of Product Backlog Items and take it literally. They expect to have every single item delivered at the end of the Sprint, at any price. And, what is even worse, they begin making plans, assumptions and decisions based on this not yet confirmed fact. Then, if the commitment is not fulfilled, they may try to “claim their guarantee”, and ask for liable individuals. This is especially frequent when the business has not yet gotten rid of their former command-and-control, non-agile project management mindset.
If we have a look at the Development Team, many times the situation is not better. The team takes the commitment as a venture aimed at delivering every single bit of functionality which was promised at the beginning of the Sprint - once again, at any price. The only indicator for success is reaching the X-axis in the Sprint Burndown, the sooner the better, and sometimes even at the expense of software quality or the real business value being delivered.
I frequently find Development Teams, whether inexperienced or with a pretty broad Scrum background, putting the fulfillment of the entire commitment above anything else. They take it as a replacement for the real goal (which we are going to refer to in a moment). If they fail the commitment, they will express - maybe at the Retrospective – their disappointment with themselves, or try to find someone to blame inside the Team, instead of taking the opportunity to inspect, learn and adapt to improve for subsequent Sprints.
Either way, whether the commitment concept is abused by the business people or by the developers themselves, the usual victim is product quality, as Ken Schwaber himself has repeatedly pointed out.
The Development Team is pushed under the wrong kind of pressure, and the team members find themselves struggling to deliver each and every one of the selected Product Backlog Items by means of rushing, taking shortcuts, accumulating technical debt and not fulfilling the Definition of Done.
As a logical consequence, the Development often starts to pad its estimates to avoid the permanent pressure vise. Hopefully, getting rid of the word commitment in favor of forecast will help Scrum Teams avoid these pitfalls, and focus on what really matters.
Ok, I can see the advantages, but are there any drawbacks?
At a first glance, one evident drawback could be the difficulty in getting used to the new term. We could find it difficult to begin adopting “forecast” for upcoming conversations and writings, or to remember the reasons for the change when reading “commitment” all over the already written material. Well, I think that in fact it’s not that hard to get into the habit, and the potential benefits are well worth the effort.
Besides that, there may be another (apparent) obstacle. At first sight we may think - maybe some people are mistakenly already doing so - that changing commitment by forecast will drive Development Teams to believe that they can happily relax, and assume that they can finish any Sprint without delivering a usable increment of software. Since it’s only a forecast…it’s not our fault if we don’t manage to get any single item done, right?
Well…actually “commitment” remains there. As you can see for yourself, the Scrum Guide only refers to forecast when dealing with the list of Product Backlog Items selected for a Sprint. But for any hardly competent person working as a developer, commitment is still present in Scrum and, furthermore, in software development itself, at all levels:
At a personal level, developers worth that title will commit to be professionals, striving always to do their best at work, given the available environment and resources. Dan Pink describes this fact in his book ‘Drive’.
At the values level, any Agile developer will of course commit to value people, working software, collaboration, and responding to change. He will surely commit even further than that, and go for technical excellence, continuous learning and improvement, team building and the whole set of Agile principles.
And what about Scrum? Is still any commitment there? You’d better bet for it. At the Scrum framework level, developers:
- Commit to fulfill the Sprint Goal, which if well-crafted, tells the Development Team members why they are building the Increment. Unlike the list of selected Product Backlog Items for the Sprint, the Sprint Goal is coarse enough to allow the Development Team to navigate and satisfy the commitment. This avoids anyone blindly expecting that any single selected item will be delivered under any circumstance.
- Commit to assure that they deliver a usable increment at the end of the Sprint, which includes only items that are fully finished according to the Definition of Done that has been agreed to beforehand.
- Commit to continuously inspect and adapt, to better support the empiricism that lies at the heart of Scrum.
- And at the end, commit to the values and elements that build up the framework, which allow us to tell that we are doing Scrum instead of anything else.
Conclusion
In Scrum, the Development Team is now asked to forecast the specific work that can be done in a Sprint, rather than “commit” to it. This allows teams to focus on the things that matter in professional software development like quality, value, and continuous improvement, rather than satisfying an arbitrary obligation.
Business-facing people (Product Owner, stakeholders, customer…) must recognize the inherent uncertainty in building software of any real value and complexity. Their responsibility is to create an environment where Development Teams can succeed, and trust in those teams’ professionalism to do all they can to deliver things of value.