Where’s the Commitment?

From the The Reluctant Agilist Blog
Adam Weisbart | Agile | Agile 2013 | agile 2014 | agile 2015 | Agile 2017 | Agile Alliance | agile coaching | Agile Metrics | Agile Practice | agile transformation | Agile Transition | agile2014 | agile2015 | agile42 | Agilistocrats | Alistair Cockburn | autism | Bas Vodde | BigVIsible | book review | Brian Bozzuto | carson pierce | Center for Non-Violent Communication | Certification | Chet Hendrickson | Chris Li | Coaching | commitment | Communication | conteneo | Craig Larman | cross functional teams | CSM | CSPO | Daniel Gullo | Dave Prior | David Anderson | David Bernstein | David Bland | David J Anderson | Dhaval Panchal | diana larsen | Digital Agency | Digital PM | digitalpm | Don Kim | dpm | dpm2013 | drunkenpm | drunkenpm radio | eduscrum | emotional intelligence | empathy | Enterprise Agile | Essential Scrum | esther derby | Excella | Gangplank | Gil Broza | Howard Sublett | Individuals and Interactions | Jean Tabaka | Jesse Fewell | Jessie Shternshus | jim benson | johanna rothman | john miller | Jukka Lindstrom | Jutta Eckstein | kanban | Kanban Pad | kanbanfor1 | Ken Rubin | Kenny Rubin | Kim Brainard | lacey | Large Scale Scrum | Larry Maccherone | LeadingAgile | lean | Lean Kanban North America | LeanKit | LESS | lkna | luke hohmann | lyssa adkins | Maria Matarelli | Marshall Rosenberg | Michael Sahota | Mike Vizdos | Modern Management Methods | modus cooperandi | Natalie Warnert | Nic Sementa | Non-violent communication | NVC | Olaf Lewitz | Øredev | Øredev 2013 | organizational agility | Organizational Change | overcommitment | Patrice Colancecco Embry | Paul Hammond | personal kanban | personal productivity | personal project management | Peter Saddington | PMBOK | PMI | PMP | podcast | Product Owner | Product Ownership | productivity | project management | Project Management Institute | Rally | reluctant agilist | retrospective | Richard Cheng | Roman Pichler | Ron Jeffries | SAFE | Safety | Sallyann Freudenberg | Scaling Scrum | Scrum | Scrum Alliance | Scrum Gathering | ScrumMaster | self organizing teams | SGPHX | SGPHX 2015 | Shane Hastie | SolutionsIQ | SoundNotes | sprint planning | Team | teams | Temenos | The Improv Effect | Things | Tom Perry | troy magennis | User Stories | value | Vivek Angiras | waste | Waterfall | What We Say Matters | why limit wip | women in agile | Woody Zuill | show all posts

About this Blog


Recent Posts

Jurgen Appelo - Agility Scales

Head First Agile with Andrew Stellman and Jenny Greene

Making Agile Work at HUGE Inc. w/ Lance Hammond and Robert Sfeir

Reframing Technical Debt as Technical Health - with Declan Whelan

Bob Tarne - Agile and Design Thinking

Categories: Scrum


The Scrum Guide is the document created and maintained by Ken Schwaber and Jeff Sutherland at Scrum.Org and it serves as their definition of what Scrum is. A recent change to that document has the potential to significantly alter the way many people look at Scrum.

Here is the definition of the change as defined in the update notes:

Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint.
(See: http://www.scrum.org/storage/Scrum Update 2011.pdf)

For some, the switch from commitment to forecast will be simply semantics and not a point of concern. But I believe that removing the idea of making a “commitment” and changing it to “forecast” has the potential to be a very dangerous change for Scrum. For high performing, committed and focused teams, this may not present a issue, but for the teams that are just beginning a transition to Scrum, or struggling with the discipline required to follow the process, this change has the potential to make it “OK” to not deliver potentially shippable code in any given Sprint.

In Scrum, at the end of the Sprint Planning meeting, the Team makes a commitment to the Product Owner. The team commits to what stories it says it will get done during the Sprint. While it is not expressly stated as such, this commitment is basically the Team saying to the Product Owner (and thereby to the Business), “if you are available to us for questions when needed, and otherwise do not disturb us or try to alter what we are agreeing to do, we will have these stories completed and ready for review by end of Sprint.” This may sound simple, but there is a lot going on here.

First, the Team is saying that they’ve looked over the prioritized work, and with their current (but admittedly incomplete) understanding of what is being asked of them, they feel enough comfort with their knowledge of the stories, the project, the process of getting work done and accepted, and their own capacity and abilities as a team, that they can take responsibility for getting that work to a state of potentially shippable by end of Sprint.  So, while each Story Card may only represent a conversation, enough work has been done breaking it down into tasks and understanding the acceptance criteria that the Team is willing to be held accountable for it.

Accountability is a critical part of Scrum. Once the Team makes the commitment, they are responsible for it. If they’ve over committed, they still need to get the work done. If one team member becomes ill or is otherwise not able to perform their role, the Team still needs to get the work done. There are times when, for one reason or another, the Team can’t complete the work. If there is a valid reason for this, they should feel no fear about reporting to the stakeholders in the Review Meeting. If, however, they are just not getting it done, they should experience a significant amount of discomfort at having to explain their failure to meet commitment to the people whose budgets are paying for them.

For the Team, commitment is important because it carries weight, and the Team should feel the burden of that on their shoulders. However, the Team should NEVER commit to things it does not feel it can accomplish. This is something that they need to defend. No one is going to praise them for not doing what they say they’ll do. The promise of Scrum is that you get potentially shippable product at the end of every Sprint. When a team commits to things it does not believe it can do, it is basically committing to failure. Scrum offers the Team great power and, as Uncle Ben said, “With great power comes great responsibility.”

In addition, as it is working through the Sprint, the Team should be monitoring its progress towards meeting the commitment. Anytime an individual works on something that does not contribute to meeting the commitment, the team should work to correct that because it is the other team members who have to pick up the slack.

It is also important to note that it is not just the Team that is making a commitment. When the PO accepts the Team’s commitment, he does so on behalf of the Organization. The PO’s part of this commitment involves ensuring that she is available to the team as needed to provide additional information about the features defined on the story cards. It also means that the PO is agreeing (on their behalf as well as the organization) to not introduce change into the Sprint once the commitment has been agreed upon and to not otherwise disrupt the team (or permit the Organization to do so).

This two-way commitment is the basis of trust for the Sprint. When a commitment is not met, the trust is endangered. If this happens and the Team cannot determine why and make necessary corrections, it may result in the team repeatedly failing to meet its commitment. At this point, the idea of a Team commitment becomes invalid, and the lack of accountability places us more or less back where we were before taking on Scrum.

In many ways, Agile is a privilege, not a right. Teams should treat it as such and be respectful of the idea that “with great power comes great responsibility.”

Posted on: July 26, 2011 02:01 PM | Permalink

Comments (5)

Please login or join to subscribe to this item
Hi Dave,
I think the language change is meaningful and sends a signal that the commitment based paradigm is suboptimal. "Forecast" does not mean commit, and Sutherland and Schwaber's description seems to support that when they state, "Development Teams do not commit".

I was also struck by the tone of your commitment description. I took the liberty to pick out a few terms in your blog:

burden ... on their shoulders
... pick up the slack

If commitment based sprints are defended with that type of language, maybe it's an indication of the problem that prompted the change to begin with?

There will be plenty of opinions on the continuum of support and opposition. This is my first, but certainly not my last, public comment on the matter. At the Scrum Gathering in Minneapolis several years ago, Ken S. stated that notion that there would be or should be a Scrum 2.0 was illogical and groundless. Scrum was so simple and pliable that users could adjust it as they desired, but the more they strayed from the core, the more it became the proverbial "Scrum, but." I feel that Dave has solid, reasonable points regarding his opinions about the commitment matter and selecting and isolating words he chooses to describe his feelings and other points is a bit absurd to me and smells of familiar tactics used by some talking heads.

The underlying troubling issue for me in this matter is whether any one, two, three or four people can legitimately lay claim that they are definitive source of Scrum knowledge and can unilaterally institute change that may not even have been warranted or desired. It smells strongly and fervently bad to me. This has always been a “community-based framework” and any claim to being definitive authoritative regulator of its content and practice was surrendered long ago. To operate otherwise, a person would have to have a legitimized right to the content. The Scrum Guide is, indeed, the work of Schwaber and Sutherland, but that doesn’t make it or them anymore authoritative or regulating than Norm Geisler is to the Christian religion. Of course, Schwaber and Sutherland should be respected and admired as the creators of Scrum and their opinions should be appropriately honored, but to decree that their Scrum Guide is the singular, definitive body of knowledge about Scrum is really preposterous.

Those of us who use, train, teach, coach, live Scrum can appropriately decide whether “commitment” should remain a tenet of Scrum and/or whether forecast is suitable. No one person need dictate to us which we select – either, both or neither. For me, commitment remains in tact and forecast is something we can do.

What is the next thing we might see - a declaration of a change of Scrum values and principles? To me, this "anouncement" has just created undesired and wasteful noise in our community. It may provoke some worthy discussion, but such dialogue should ensue (and does ensue) without inspiration by some whimsical declaration of change. We are way beyond that point in the adoption and use of Scrum. Perhaps if a person or persons have difficulties with the 10 Commandments, they can rewrite those for more sutable use. Tha will precipitate similar discussions.

So, I’ll respect Scrum’s founding fathers as such respect is certainly due them. But, using the US Constitution as a simile,just as no single person or small group of persons can unilaterally and single-handedly make changes to that document with an “updated publication," neither can a person or small group dictate changes to Scrum. It took (and takes) the authority and support of the broad US community to foment change in the US Constitution by virtue of the defined amendment process. We don’t need that kind of process to change Scrum; it will evolve on its own as its users desire without directives and mandates.

I probably would like to present this data as some form of trigger for further thinking. How many shops have you been who claimed they are an agile shop and yet they don't complete deliverables on the desired/targetted time? How many times did you hear people we need flexibility and yet you hear the same complaint that the team is continually firefighting and submitting emergency release almost immediately after production cut-over.

I thought the whole intent of scrum is to thinly slice the pieces of a product for better quality and more efficient delivery of product from a time perspective through the application of proper techniques in product development. Scrum did not say that we can just create something fast to the detriment of quality.

Getting back to Dave's original observation, my colleagues and I think the distinction between committing and estimating (or forecasting) is critical enough that we have made it our central tenant of our approach - Commitment-based Project Management.

As Dave points out, having each member of the team taking responsibility (for not only his or her pieces, but for keeping the project on track to it's goals) changes the whole dynamic and is the best and maybe the only way to build trust and confidence among the entire team. Teams who can see that they are consistently able to accomplish what they said they would make even stronger commitments in the future (build commitment muscle), which comes in handy when the overall scope inevitably evolves. The Agile philosophy is very clear about enabling the creation of high quality outputs, but it should not be forgotten that a team that can deliver quality products with a degree of predictability (around timing) is more valuable than a team that eventually creates quality outputs, but never knowing when it will be releasable, until it is.

In our experience there is more to operating from personal commitments than just adhering to the scrum steps. Taking the fear and blame out of speaking up, when a commitment is in jeopardy is critical and requires leadership. We are committed to the notion that this leadership can be taught/learned.

Thanks Dave for not letting this critical declaration go un-tested.

I wholeheartedly concur with Dave's assessment of this change. A core theme of traditional project management and software development has been distrust. The relationship between business stakeholders and creative workers in IT has been adversarial and contractual with formal approval processes, change management, sign-offs, gates, etc. The purposes is to build a web of protection and a path for blame.

With Agile, the goal is to build a partnership and instill trust. Trust is like a savings account, you start off with an initial deposit but then based on stuff that happens, there are either further deposits or withdrawals. When a team defines their Sprint Backlog and then doesn't deliver, it's a withdrawal from the Product Owner's account; i.e. it damages their credibility and ultimately, the partner relationship and collaboration.

If the problem is uncertainty 3-4 weeks out, then maybe the project needs to move to shorter Sprints to improve the Scrum Team's ability to "forecast" what they can commit to. Perhaps there are other strategies or things that can be tweaked to make commitment happen; but happen it MUST.


Please Login/Register to leave a comment.


"One of the symptoms of an approaching nervous breakdown is the belief that one's work is terribly important. "

- Bertrand Russell