The Agile Manifesto for Software Development
was forged in 2001, largely as a backlash against management control of software estimates, scope, and deadlines. It paved the way for Agile frameworks like Scrum to allow those actually developing software to determine their own estimates, schedules, and release content, along with a commitment from management to let teams self-organize and no longer attempt to control a process they didn't understand. In exchange for this newfound freedom, software development teams were now expected to commit to delivering smaller increments of software more frequently than before. This required teams to plan work as best they could, then make a "commitment" to actually deliver. If delivery was not as expected over time, Scrum would fail and management would again be in the driver's seat. The concept of a sprint "commitment" has been around for about a decade. In 2004 Ken Schwaber stated:
One practice that slowly and then exponentially adds productivity to the team is its commitment to its work and the team members' commitments to each other. A team says that it will do something, and it does whatever it can to do so. Team members commit to each other that they will do something, and they help each other out whenever necessary.1
Although this was the prevailing mentality for ten years, in 2011, Schwaber and Jeff Sutherland (both originators of Scrum) replaced the traditional Sprint "commitment" with the concept of a "forecast":
Commit to scope with a sprint is gone. Instead, development teams now create a forecast. 2
In Mike Cohn's blog on 6/28/12 ("The Rules vs. the Generally Accepted Practices of Scrum"), Mike completely justifies continuing the practices eliminated in The Scrum Guide
(without specifically referring to the guide) if those practices fulfill the definition of a "GASP
A Generally Accepted Scrum Practice (GASP) is an activity performed by many, but not necessarily all, Scrum teams. A team that does not perform the practice can still be considered to be doing Scrum. . . . In contrast to a GASP, a rule is an inviolable thing that if a team isn't doing, they aren't doing Scrum.
The concept of the sprint "commitment" also remains part of the Learning Objectives
published by the Scrum Alliance for Certified Scrum Trainers for use in their curriculum for the Certified ScrumMaster (CSM) course. In addition, the sprint commitment is referred to in the most recent popular literature describing the Scrum framework.3
The intention of this article is not to debate whether Scrum teams make a commitment at the end of sprint planning. For those teams that do make sprint commitments, however, I think it is mandatory that both the ScrumMaster and
the product owner participate in that commitment.
In a comment to Serge Beaumont's blog from 2010, Geert Boosuyt says:
To "commit" is about daring to make choices, as a team or with your product owner, which will still lead to delivering the promised goal.4
Over the last ten years I've witnessed innumerable sprint planning sessions in which the development team would commit to the product owner (and sometimes to the ScrumMaster -- which is forbidden!) to deliver the sprint backlog. Then, within a day or two, the product owner would make changes to the backlog, or perhaps not be available to answer functional questions for days. Meanwhile the ScrumMaster would neglect to perform the basic elements of that role,5
often failing to protect the team from outside forces as well as ignoring impediment removal. Product owners and ScrumMasters can thus be the direct cause of sprint failures.
Serge Beaumont's blog (referred to above) includes the following "condensed" version of the traditional "fist of five," often performed by teams at the end of a sprint planning session. As we all know, the idea is for each team member to simultaneously extend from one to five fingers, indicating their relative degree of confidence in completing the iteration on time as just planned:
Not a snowball's chance in hell!
I don't think it's possible . . .
There's a 50/50 chance that we'll make it.
We have a reasonable chance of making it (80 percent).
It's a sure thing!
If too many team members exhibit fewer than four fingers of confidence, the team should discuss all concerns, perhaps reducing the backlog until everyone extends four or five fingers in support of the plan. I still find this practice to be invaluable and try to require both the product owner and
ScrumMaster to participate. If either the product owner or ScrumMaster causes the team to miss a commitment, that should be raised during the retrospective, along with a specific action to address the cause of failure. Having the PO and SM participate at this level also reinforces their importance in the process. Without proper participation and support from product owners and ScrumMasters, Scrum will fail.
1. Schwaber K. Agile Software Development with Scrum.
2004. Microsoft Press, Chapter 8, "The Team."
2. See The Scrum Guide Revision History for July, 2011: http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide_Revision_History.pdf
3. Two of the most recent books covering Sprint commitments include: Rubin K., Essential Scrum: A Practical Guide to the Most Popular Agile Process.
2012; Addison-Wesley Professional; and Viscardi S. The Professional ScrumMaster's Handbook
. 2013; Packt Publishing, Ltd.
5. Here's (what I think is) a good description of the ScrumMaster's role: http://www.scrumalliance.org/articles/52-empowering-teams-the-scrummasters-role