In part one of this series (see “Commitment Issues“), we discussed the use of the word “commit” in sprint planning, and how it can make for a bad situation on teams. Promising to deliver a set of stories, weeks in advance, can invite scenarios in which the wrong things are being worked on; quality suffers when it is determined that the work is more extensive than originally thought; or negative feelings develop between teams when a promise isn’t kept. As it happens, the original founders of Scrum, Ken Schwaber and Jeff Sutherland, acknowledged this issue and, in 2011, revised the official Scrum Guide to address it.
This was a positive change, as it took developers out of the business of making promises that they didn’t know if they would be able to keep. It also makes the agile process even more agile by allowing the team to use all available knowledge gained, no matter when that knowledge comes into the team. This may uncover other causes of change that would otherwise be misunderstood; not meeting the desired outcome of a sprint often can be examined as a learning opportunity, rather than one that punishes the developer (or product) team.
Let’s take a look at three ways that teams can avoid commitment issues in the first place.
1. Using Forecasts
When product or business owners are asked to enter in user stories that they want
Please log in or sign up below to read the rest of the article.