Commitment: Why and How
At the peak of sprint planning the team pledges “We commit to achieve these stories, no matter what it takes“. It’s a deal with the Product Owner (PO) and the team.
So why do teams commit?
The commitment is only valuable if the team thinks it can actually achieve it. Since the team is invited to pull the right amount of stories from the backlog, the PO trusts that the team makes reliable commitments based on their current capabilities and expected flow. This way the self-organizing team is challenged to constantly improve estimates, deliver value, as well as contribute its stake in risk management.
And how to arrive at a commitment?
- prepare stories in Product Backlog well
- discuss to make sure stories are understood
- confirm the acceptance criteria (get early feedback from customer and PO)
- discuss implementation order vs. prioritized stories
- consider Retrospective findings, refine Definition of Done if necessary
- re-estimate if needed
- consider need for spike (experiment sprint)
- recognize the right amount of refactoring and tuning requests to reduce technical debt
- commitment is always on the story, not on its tasks
The product owner’s trust shall never coerce the team into committing a set of stories they do not feel comfortable achieving. If the team turns out to overcommit and needs to de-scope stories during the sprint, that is part of the intended feedback cycle reflected upon during retrospective, thus it will gradually increase its certainty.