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.”