agile15: Commitment: Why and How

At the peak of sprint planning the team pledges "We commit to achieve these stories, no matter what it takes". ...

15 September 2010
Scrum & XP
agile15, commitment, scrum, scrum tools

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.

Further reading: Succeeding With Agile; Commitment-Based Planning

Subscribe to new blog posts

Did you find this article valuable? To be promptly noticed of new blog posts by agile42 you can subscribe to our notification system via email.

Discussion 2 Comments

Actually, according to the Scrum Guide, the deal between the Team and the PO is to do their very best to reach the Sprint Goal. The planned Sprint Backlog Items (User Stories, if you will) are just the initial plan of how the Sprint Goal might best be reached. When it becomes apparent that it isn't a realistic plan, the PO and Team come together again to negotiate on how to change the content of the plan so that the Sprint Goal still can be reached. If that's not possible, the sprint gets cancelled and after some reflection, a new, more realistic Sprint Goal gets negotiated.

In my not so humble opinion, this makes a lot of sense, because a sustainable pace is much more important than reaching some intermediate Sprint Goal. At the start of a Sprint, we obviously only can make an educated guess on what is possible. When we learn something new, the right thing to do is to incorporate that learning into our plan, not to blindly follow a plan that we have now learned doesn't make best sense.

Hey ipreuss,
you are certainly right, and nobody said that the commitment is an unbreakable deal, on the other side you don't want to coach a team and tell them that it is not so much important to commit as they could renegotiate the Goal during the sprint anyway.

In the original paper on Scrum, the "Iteration" is presented as a pattern to allow the best compromise between the Business willing to wait a certain amount of time before actually planning more things, and the development having the need to focus and solve one requirement after the next, possibly without having moving target on a daily basis.

Collaboration in a Scrum Team is the core of success, nobody would like to have a deal that generates a wall, on the other side though, we verified many times that a team dialog to try to identify to what to commit, generates that sense of urgency which brings focus, and allow the team to concentrate on the most effective way to reach a goal. Without commitment taken seriously, the "empowerment" of a team might look a bit like a give without any take :-)

So I agree with your approach, as nobody talked about following a plan, but rather reach some committed goal, however the team would choose to. Inspection and Adaption would allow the team to re-evaluate the initially thought approach at least at every Daily Scrum, so no plans sticks... and the team is still agile ;-)

Comments are closed.

Comments are closed.

Comments have been closed for this post.

Latest entries

Managing Work Without Resource Managers

Moving to self-organized teams causes a manager’s role to change focusing on creating a safe-to-fail environment, ...


Growing Agile at Keep Austin Agile 2017

agile42 sponsors Keep Austin Agile 2017, with sessions by Dhaval Panchal and Dave Sharrock


Resilience and anti-fragility at HAPPYPROJECTS 17

Andrea Tomasini will speak at HAPPYPROJECTS 17 in Vienna


Sponsorship of Mile High Agile 2017 in Denver

agile42 sponsoring MHA17 in Denver, 22-23 May 2017 featuring a talk by Richard Dolman and Dhaval ...


The Agile Pubcast from SGMUN with Andrea Tomasini

Andrea Tomasini was a guest episode 13 of the Agile Pubcast podcast to discuss the coaching ...