As an Agile coach and trainer, I have a love-hate relationship with the idea of a “Sprint Commitment” for Scrum teams. That is, I love the idea and spirit of it, but I hate how the term ‘commitment’ generally gets abused.

What everyone involved – especially managers and executives – needs to understand is this: a team commits to a sprint goal in the same way that a sports team commits to winning a game they’re about to play. That is:

1. The team’s sprint goal (or game) is their top priority. They’re not going to allow themselves to be sidetracked by competing priorities or distractions.
2. The team recognizes that others are counting on them and that folks outside the team will be negatively impacted if the team doesn’t deliver.
3. The team is going to give their best effort.
4. The team will be creative when faced with difficulties in achieving the goal and adapt to the changing situation.

An Agile team does not commit absolutely to achieving a sprint goal. They can’t. There will be things outside of their control that can prevent them from succeeding. Even if that were not the case, the team does not commit “at all costs.”

When sprint commitments are interpreted in those ways, the organization’s risks are being transferred to the team, rather than being borne by the larger organization. If those risks obtain, the associated costs will then be borne by the team as well. This might be in the form of longer hours, increased stress, routine maintenance activities being deferred and that will come back to bite them later, etc.

For example, consider a team that has committed to achieving certain stories by the end of the sprint. Once the sprint begins, though, critical SMEs are unavailable to answer questions or provide input. The team finally receives the information they need – but only two days before the end of a sprint. When they alert stakeholders to the fact that they will not be able to achieve all of the stories, they are accused of “breaking their commitment” and told that they need to meet that commitment. The team feels that they have no choice – they stay late at work, they start cutting corners invisible to others (technical debt), their stress levels rise, etc.

Predictably, when risks (and then costs) are externalized onto teams, teams adapt and compensate. They sandbag. They inflate their estimates. They treat minute tasks as distinct stories needing story points. They insist that requirements be written in stone down to the nth degree. And so on.

Those behaviors are all symptoms of the team attempting to protect themselves from having the organization’s costs externalized onto them. The organization needs to bear its own risks and costs. Once the team trusts that they will no longer be left holding the bag, many dysfunctions will evaporate – but it is a long process. Trust is not built overnight.

As a first step in managing these risks, sprint goals can be framed in terms of “assuming x, we commit to accomplishing y.” Simply by calling out the assumptions, the team makes those risks visible to stakeholders, who may then be able to take action to mitigate those risks. At a minimum, expectations have been set and the organization can start chipping away at the fallacy of “broken commitments.”

I would like to acknowledge that I gained valuable input on this topic from Bas Vodde and Trent Hone.