Published 6 March 2013
“I don’t like the word commitment”, started Bob in a retrospective, “I don’t feel it’s fair that I’m promising the business the delivery of something that I have no control over [because there was work in the sprint that Bob would not be working on]. I’d prefer to use a different word. How about ‘target’?”.
I was a bit sad when I heard this because that’s not how I saw commitment in Scrum. I always took it to be a commitment to try to achieve x, y and z by a certain date. I was aware that the business sometimes took it to be more of a legally-binding contract, but that was part of my/our job to make them understand their error. At least, until now, I thought that the team all had the same interpretation.
But it seems even the founders of Scrum have thrown in the towel. At the end of 2011, scrum.org formally replaced “commitment” with “forecast” in their Scrum Guide. They still say that there’s commitment to the sprint goal, but not to all PBI’s (aka stories) in the sprint backlog.
It’s subtle, but significant. It’s all good on paper, but what will the effect be in the real world? Early indicators for my team using Scrum suggests that some (but certainly not all) miss the sense of commitment. Some of the developers in the team say they work better with a greater sense of commitment/pressure. Will it reduce output? Maybe. Will it actually change the business’s interpretation? Very likely.
Which is more important? I suppose that depends on your business and what commitment the business makes in response to your team’s commitment. My feeling is that it makes the whole thing a bit wishy-washy. But, hey, nobody says you HAVE to stop using commitment: do what works best for you.
