How Does a Scrum Team Deliver its Commitment?

August 13, 2008 by Peter Stevens

Every Sprint, the Team commits to deliver some functionality to the Product Owner. A lot can happen during the course of a Sprint. How does the Team know how much it can commit, and how does the Scrum Master ensure that the Team actually deliver what it committed?

There are several factors that the Team and Scrum Master have to get right, in order for the Team to meet its commitments:

1. Committing to the right amount of work
2. Accepting responsibility for the stories
3. Keeping the scope fixed through the sprint
4. Protecting the Team from external influences
5. Keeping the Team focused on what it is supposed to be doing

Getting the commitments right is a learning process for the Team. The Team members need to learn that they have committed not only to scope by the end of the sprint, but also to quality (expressed through the definition of done), and that quality has precedence. I have found it useful to categorize stories as 'Committed' or 'Conditional'. The latter are generally smaller stories which have been authorized by the Product Owner and which the Team might complete if time permits.

If a committed story is not finished, then the Team and Product Owner discuss the situation during the Sprint Demo. Conditionals are a bonus. If the Team can finish one or more, that's great, but there is no expectation that they will be completed by the end of the Sprint. From the perspective of expectation management, it is important to consistently deliver all 'Committed' stories, preferably with a 'Conditional' or two. Better to slightly under-commit and slightly over-deliver than the other way around.

Who is responsible for a story? The Team as a whole or a particular person in the Team as well? This is a question that I pass to the Team. Fundamentally, the Team commits to the story, but in most of my projects, the Team has preferred to have one team member take responsibility for each story. This "designated pig" feels responsible for it and will probably demo it at the Sprint Demo, so s/he makes sure that it works its way through through the process from accepted to done.

Preventing Scope Creep

Ensuring that the scope stay fixed is a duty of the Scrum Master. I find it useful to formalize the agreement between the Team and the Product Owner as a Sprint Contract.

During the Sprint Planing meeting, I review the definition of Done, confirm the duration of the Sprint and the available capacity, adjusting for vacation, holidays and other planned absences. This gives Time, Effort and Quality. Then the Team and Product Owner negotiate the Sprint Backlog for the Sprint. This gives the fourth parameter: Scope. After the Sprint Planing meeting, I send this "contract" (usually in the form of a short presentation that I update every month) to a the Product Owner with the subject "Sprint Contract for Sprint n". The Product Owner confirms the contract, usually with an email.

Any changes would break the contract. The Scrum Master politely refers the Product Owner to the contract when s/he tries to sneak in changes or additional work. The Sprint contract is an all or nothing item. If the Product Owner wants to, s/he can cancel the sprint and negotiate a new contract. But that is an expensive option, to be used only in emergencies.

Stay Focused

Protecting the Team can be more difficult, because an executive manager or member of another department was not a party to the contract. Staying focused is a daily challenge in any case. The basic strategy is to check with people every day on what they are doing , escalate any diversions, and to refer requests for any thing new to the Product Owner. Neither the Team nor the Scrum Master are authorized to set priorities. The daily scrum and sprint burn down chart help identify when people are being diverted from their commitments. If a team member is stuck, diverted or distracted, it becomes visible quickly.

One of the great "a-ha!" effects of Scrum is realizing that a team can make commitments and actually deliver what it promised. The Sprints are short enough and the playing rules clear enough that the sprint contract won't (often) need to be broken. The Daily Scrum keeps everybody focused and helps recognize impediments. The daily burn down chart help recognize when the team is stuck or distracted. After a little bit of practice, the team should become quite effective at committing to functionality that they will also deliver.

Permalink