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: […]
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:
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.”
Many look for tried and true recipes to help them succeed as they undertake a...
Getting Agile requirements right can be a challenge but it’s essential as they can make...