Problem solve Get help with specific problems with your technologies, process and projects.

Scrum team commitments: More harm than good

Most inexperienced Scrum teams overcommit on what they will deliver, and when. Agile leader Lisa Crispin says that does more harm than good.

Our Scrum team commits to a certain number of stories at the end of our sprint planning meeting. But we aren't...

always able to complete all those stories because of various unexpected events. Is committing a good idea?

Most inexperienced Agile teams over-commit. They are eager to please the business stakeholders, and succumb to pressure to do 'just one more story.'

As Dwight Eisenhower famously said: Plans are useless, but planning is indispensable. For Scrum teams, planning work for the next few days is a useful activity. Trying to plan ahead for two or more weeks is like planning a road trip; you can plan your route, but you may encounter unexpected road construction, traffic or a more desirable stopping point along the way.

Similarly, you can't predict production problems, user stories that turn out to be more difficult than expected, and test environment hardware or software problems that might affect how much new development a team can get done.

Most inexperienced Agile teams over-commit. They are eager to please the business stakeholders and succumb to pressure to do "just one more story." When something unexpected happens and they can't complete all the stories they planned, should they beat themselves up about it in spite of having done their best work? Or worse, should management punish them for failing to meet their "commitment?"

Another common problem with "commitment" is that developers say, "These stories are done," which means the code is written. They take credit for those story points, when, in fact, testing isn't complete because of failure to perform essential activities such as exploratory testing and regression testing.

Next Steps

Learn how to set up Scrum team roles

This was last published in January 2013

Dig Deeper on Scrum software development

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

IME PMs like the sprint planning to be a 'stretch'. That implies they accept that there is a strong likelihood that some stories will carry forward. Even if you don't [intentionally] overload a sprint, aren't the daily scrums the opportunity to respond to unexpected events (as well as all other informal collaboration thru-out the day). A having a solid 'definition of done' (that should clearly include at least functional unit tests and perhaps other types (non-functional, integration, etc), should combat the desire to make an premature claim about story being complete.
I'll agree with the concern about needing to have a clear definition of what "done" means but I do not agree that teams should not be expected to make commitments for 2 - 3 week sprints.

There is some necessary learning about what the teams true velocity is but if the work is so uncertain that you can't have predictability beyond a couple of days horizon I would be extremely concerned about ever delivering something of significance.

One approach I've seen to dealing with the "cone of uncertainty" around new technology or innovation is to schedule investigative stories in a sprint to resolve some uncertainty before committing to delivering working code in a future sprint.
My experience has been that developers are usually a bit optimistic about how fast they can get something done, and PM folks are always pushing for more. These combination of factors leads to people being mostly wrong about what can be done in some period of time.