Blog

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". ...

On
15 September 2010
In
Scrum & XP
Tags
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

    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

    agile42 Insights: How Do You Cultivate a Great Team?

    How to grow a high-performing Agile team, the need to handle conflict and more advice from ...

    0 Comments

    agile42 sponsoring Manage Agile 2014 in Berlin

    agile42 will be a sponsor of Manage Agile 2014, in Berlin 27-30 October 2014

    0 Comments

    My understanding of effective Agile Coaching

    Effective Agile coaching is the process of supporting the client to improve by becoming Agile: it's ...

    0 Comments

    agile42 invites you to Lean Kanban Southern Europe 2014

    agile42 is organising the Lean Kanban Southern Europe 2014 conference in Bologna on May 30th, an ...

    0 Comments

    MHA2014 Sponsorship and Speakers

    agile42 is proud to be Gold Sponsor of Mile High Agile 2014 and will have two ...

    0 Comments