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.
This was first published in January 2013