Commitment in sprint

Prepare for success

A commitment-driven sprint planning meeting involves the Product Owner^[1], Scrum Master and all development team members. The Product Owner brings the top-priority product backlog^[2] items into the meeting and describes them to the team, usually starting with an overview of the set of high-priority items.

When it comes to commitment, there are no grey areas. Either you are committed or you are not. Commitment of a team is the key to manage customer expectations, to make things plannable and to make things happen. Next to pursuing happiness, commitment is one of the most fundamental principles of success. This is why we talk about a commit-driven sprint planning.

How

Select an item

Following the top-priority product backlog items, the team members select a first item to bring into the sprint. This will almost always be the product owner’s top-priority item, but it is possible that the product owner’s top priority has too many open issues. Ideally, a team should be able to still bring that item into the sprint and resolve the issues early enough in the sprint to complete the item. But, it’s possible that there are so many issues, that the issues are so significant, or that resolving the issues would take so much time that the product owner’s top priority is skipped.

Tasks and hours

Having selected a high-priority item, team members discuss the work involved, and identify the tasks that will be necessary to deliver the product backlog item. Either concurrent with identifying the tasks or immediately after they finish doing so, team members roughly estimate the number of hours each task will take. Do not ask or expect a team to think of every task that will be done during the sprint. Not only is that impossible, it is also unnecessary. Teams should think of enough of the tasks that they feel they have thought through the work—but it is important to realize that thinking through the work is the real goal of this meeting. Identifying tasks and hours is secondary.

Asking for commitment

After they’ve identified tasks and roughly estimated the hours for that one product backlog item, the team members ask themselves, “Can we commit to this?” It is very important that the team members ask this collectively of themselves rather than having a Scrum Master ask, “Can you commit to this?” When team members ask, “Can we commit?” they are committing to each other rather than to the Scrum Master.

Conditions

What are the conditions to give a commitment to the Product Owner?

Definition of ready^[3] for each story is clear:

Stories have to be refined, actionable and clear for all team members.
If a story is not refined enough it is hard to give a commitment.
You should then plan extra refinement during the sprint or do not commit to this particular story.
Definition of done^[4] for each story is clear and accepted by the team and Product Owner.
The team must give an explicit commitment per user story^[5], asking themselves: “Can we commit to this?”

The Product Owner may not negotiate in story points. Of course the Product Owner is allowed to ask critical questions, but the team always has the last call when it comes to commitment.

Deviations

If things aren’t going to plan, when may you deviate from your commitment?

Although you and your team are always trying your best to stick to your commitment, an impediment can come up which results in not being able completing a story before end of the sprint. As soon as the impediment arises it is brought up in the daily standup. If the impediment is not directly solvable, the Scrum Master communicates the impediment and accompanying consequences to the Product Owner. The Product Owner can than decide to, for example, take this or another story out of the sprint and put it back on the product backlog or (in a specific case) stop the sprint as a whole and execute a complete new sprint planning.

Definition of Done

The team has committed to the sprint goals and uses everything within their circle of influence to get the job done.