ScrumMaster and Product Owner Sprint "Commitments"

19 July 2013

John Hill
IconATG


 
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:

1 finger: Not a snowball's chance in hell!
2 fingers: I don't think it's possible . . .
3 fingers: There's a 50/50 chance that we'll make it.
4 fingers: We have a reasonable chance of making it (80 percent).
5 fingers: 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.
 
References
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.
4. http://blog.xebia.com/2010/03/24/commiting-to-a-sprint-and-failing-is-a-good-thing/.
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 

Article Rating

Current rating: 4 (1 ratings)

Comments

Glen Wang, CSM, 7/21/2013 10:08:17 PM
The key point is, make PO and SM as pigs along with team.
Bhoodev Singh, CSP,CSM,CSPO, 7/23/2013 12:44:21 AM
PO and SM roles are support and commitment both. To downstream team it's support and to upstream team it's more commitment.Scrum team can not commit sprint without their support.Both of their support play a critical role to meet the sprint commitment.
John Hill, CSP,CSM,CSPO, 7/24/2013 3:05:13 PM
Glen and Bhoodev: Thanks for agreeing with my perspective. You both really "get it"(and understand the ScrumMaster and Product Owner roles). You may (or may not) be surprised by the number of teams claiming to be practicing Scrum that do not properly understand these roles!!! Thanks again, John H.
Greg Manto, CSP,CSM,CSPO, 7/30/2013 6:38:00 AM
Food for thought...if a Scrum Team did not have a SM, could it forecast and commit and be successful? For the success of the individual / team / organization /company, is it useful to envision a future spot where that is achievable? If these same questions were posed to a new Scrum Team, would the answer be different? How about to a mature Scrum Team?

I've found this useful in revealing some interesting assumptions and expectations regarding "what's next?". I'd be interested in your thoughts.
John Hill, CSP,CSM,CSPO, 8/14/2013 4:40:19 PM
Greg: Apologies for the slow response (I haven’t been on the SA site for a while and just now saw your comment). I believe that the ScrumMaster role (impediment removal, protection of the team, etc.) will always be essential, irrespective of who performs the function. It’s very difficult for more than one individual on a team to perform this function (as you know, it can take a sustained concerted effort to remove some impediments). When the role is performed by team members with tasks in the sprint backlog (e.g., the Development Lead), we usually see that individual fail as both a ScrumMaster and in their role as part of the development team. Granted Scrum (and Agile in the broader sense) is moving away from prescriptive frameworks with less structure and more collaboration at the team level. I can’t wait to see “what’s next”! Thanks again for your comments! John H.

You must Login or Signup to comment.