As a result of Sprint Planning, your Scrum team has made a commitment to completing a certain set of Product Backlog features. This act is a public commitment, with the team’s Task Board visible to all. The ScrumMaster even sent out an email to all stakeholders outlining what the team committed to in this Sprint. However, during the course of the Sprint unforeseen problems emerge…
The team is faced with a quandary. The team cannot meet its Sprint feature commitment while supporting its other commitments to high-quality, well-designed code (related to the definition of “done”) and sustainable development. The ScrumMaster takes action on behalf of the team and removes features from the bottom of the Task Board, reminding the team that, “A commitment is not a guarantee!”
As a team member, how does that make you feel? How do you think the Product Owner or other stakeholders feel?
Not meeting a commitment once every now and then is a good thing. It demonstrates that a team is not under-committing and leaving untapped potential on the table. However, when a team is faced with the possibility of not meeting a Sprint commitment, the default answer does not always have to be to remove features from a Sprint, either.
The team needs to keep in touch with the business – via the Product Owner – to understand the full nature and impact that missing a commitment will have. After all, the Product Owner didn’t prioritize this work casually; the business is counting on the team for delivery. Be fair to the Product Owner and have the conversation first! Frankly, the team needs to ask itself if working some overtime to meet a critical commitment is warranted.
Don’t get me wrong, I totally agree with the concept of sustainable development, and I further agree that there is far too much overtime being demanded in the software world today – with very negative and unproductive long-term results. But let’s guard against swinging back too far in the other direction with Agile development. Sustainable development does not need to translate into, “No overtime, ever.”
And regardless of whether a team misses a non-critical Sprint commitment or works overtime for a week or two to meet a critical Sprint commitment, the team needs to do one more thing. The team needs to honor the commitment to continuous improvement and ask why – 5 whys – that led to the problem.
Missing a commitment should be viewed as a good problem. The team made a commitment to complete a certain amount of work – work that the team felt that it could accomplish at the outset – and it needs to explore where and why something went wrong to determine if this is an indicator that something else needs to be addressed to mitigate problems with future Sprints. Are there problems with the User Stories? The code base? Did grooming and planning fail to take something into account that future Sprints will need to consider? The earlier that a team uncovers something that will have ripple effects related to release planning, the better for all concerned.
Just as prioritizing features should not be done casually, the removing of features from a Sprint should never be a casual affair! It will have an effect on everyone, including those on the team. Removing of features is the breaking of a commitment, and while we all understand that a commitment shouldn’t translate into a guarantee, people on the team won’t feel good about themselves by breaking a commitment too easily.
The best option is that the Product Owner to evaluate the situation and make the call; if the team has been performing well and those features aren’t critical, then a discussion between the ScrumMaster and Product Owner will be beneficial. The Product Owner can be the one to say that he or she is good with removing the features on behalf of the team. The team will come away feeling supported versus feeling like they’ve failed.
If you’ve read between the lines, there is an underlying commitment that we all must have – at an organizational, team and individual level – and that is being committed to doing our best; of working smarter, not harder. If anything, we should be working harder at getting smarter.
How to Build a Button
2 days ago