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.
Learn how to set up Scrum team roles
Dig Deeper on Topics Archive
Related Q&A from Lisa Crispin
Agile leader Lisa Crispin explains a more organic, more Agile approach to test reporting. Continue Reading
When it comes to Agile planning, average time over many iterations is a more important metric than individual story estimates. Continue Reading
Lisa Crispin offers several tools and techniques for translating business requirements and gaining insight into team members' roles on project teams. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.