The Sprint Contract

Working with Scrum, I have found the metaphor of a “sprint contract” to be helpful in understanding the relationship between Product Owner and Development Team, and for protecting the whole team from outside interference.

When quality, cost and time of each sprint remain fixed, you can monitor overall progress by measuring delivered scope.

A Scrum project can be considered a series of mini-projects. Each project adds additional functionality to the product. This is known as an iterative, incremental approach, and these mini-projects are called sprints.

Like for a project, the parameters time (sprint length), quality (definition of done), cost (team size*sprint length), and scope (sprint goal and forecast) define the sprint. Unlike a classical project, a sprint is relatively short and has always the same length.

Every sprint, the Team delivers something called the “product increment” that could be shipped or deployed: it will work, it will be on time, and it will stay within the budget for the sprint. Because there is uncertainty in how much they can get done, the Team may accomplish more or less than they had forecast.

Each sprint concludes with a demonstration to stakeholders. This is an opportunity to reflect on what has been developed and learned, and what could be done as next step. Usually, the product backlog is changed as a result.

A sprint should always end on time; it should always produce at least one increment of functionality; it should be done, that is, the increment is expected to work properly; and the effort expended by the team should correspond to the normal full-time effort.

The increment might contain more or less additional functionality than was forecast. The Development Team commits to do its best to deliver the forecast functionality, but not at the cost of poor quality, delayed delivery of the increment, or overtime that would burn the team out.

This rhythm enables disciplined interactions between stakeholders and the Scrum Team to prevent waste, to enable learning and efficient decision-making, and ultimately, to build the right product.

Intended Benefit: The metaphor makes it clear that any changes break the contract and encourages the organization to respect both the Scrum process and the agreements within the Scrum Team. It also emphasizes the importance of quality and of producing an increment every sprint, even if only some of the planned features have been implemented.

Borrowing team members for another purpose breaks the sprint contract. The team doesn’t have the capacity to deliver the forecast functionality.

Extending the sprint breaks the sprint contract. The work doesn’t finish within the agreed time, so this raises the cost. Unilaterally changing the goal or the scope of the sprint breaks the contract. It is not what the Development Team and the Product Owner agreed to.

Overtime breaks the sprint contract. The Team is putting in more effort than agreed to produce the increment. It is difficult to guarantee that features are done according to the definition of done when the Team is under too much pressure, so quality is likely to suffer.

Delivering things that are not done according to the definition of done breaks the sprint contract. Fixing bugs is much more expensive than not having them in the first place, so it is generally better to deliver fewer things that really work instead of more things that will require expensive repairs later.

Structure: This is not really a commercial contract, but simply the agreement among the Scrum Team members for one sprint. It clarifies the priorities, both on the individual backlog items to be delivered and on the relative importance of time, quality, cost,  and scope. Beyond the team, it provides guidance and language to the whole organization on how it is expected to interact with the Scrum Team.

During the sprint, the Product Owner agrees to support the Development Team to get things done and not to change the goal before the end of the sprint. The Development Team agrees to support the Product Owner in getting future backlog items ready for implementation.

The rest of the organization agrees to respect the sprint contract and the Product Owner’s decisions so the Team can fulfill its commitments.

Decision Making: The Product Owner makes decisions about the product and these decisions are reflected in the product backlog. The project’s direction can be changed at the beginning of each sprint, and the project is never more than one sprint away from being able to release.

The emphasis in Scrum is on collaboration. The Product Owner brings the sprint objective, sequences the backlog, decides on the acceptance criteria for each backlog item, and has the final say whether something is done.

The Development Team estimates the individual items and gets to decide how many items they want to pull into the forecast. Items must be taken in the sequence defined by the Product Owner. Each role consults with the other to make better decisions. The whole team agrees on the sprint goal.

During the sprint, the Team organizes itself. No one, not Product Owner, not Scrum Master, nor anyone outside the Scrum Team has command authority to tell the Team how to deliver the product increment.

Only the Product Owner has the authority to unilaterally cancel a sprint and hold a new sprint planning. This can set a new sprint goal and create a new forecast. Because of the high cost of unfinished work, the Product Owner should only make use of this right if something dramatic has happened that invalidates the current sprint goal.

Scope: The Development Team agrees to do its best to achieve the sprint goal. The team will use the time available (but no more, so no overtime and no prolonging the sprint) to deliver the forecast set of features (scope) by the end of the sprint.

Regardless of whether all the features have been finished or not, the Team will produce an increment of functionality which could be shipped to the customer. Whether the product actually ships depends on whether the Product Owner agrees that there is value in doing so. Each backlog item in the Increment will be “done” according to the definition of done, as will the increment as a whole.

Risks: Changing any of the parameters, especially unilaterally or from outside the Scrum Team, “breaks” the contract and releases the Team from its commitment. Obviously, this is a bad thing, so everyone should respect the contract.

Only the scope is allowed to vary, so completed functionality can be measured every sprint.

It can be a challenge to produce something that is “done” every sprint. The Team may need to invest capacity to get good at delivering something every sprint.

Tip: Consider the backlog items in the forecast to be strictly sequenced. Implement from the top, fail from the bottom. If only one item is delivered, it should be the top priority item; if only one item is not delivered, it should be the lowest priority item, et cetera. Have a few items that are ready and approved, even though they are not in the forecast.

This encourages the Team to collaborate and focus on the most important backlog items first, and enables the team to react effectively if the sprint goes better or worse than expected: Just fail from the bottom if you have to or pull from “ready” if you need to.

Confirming the Sprint Contract with an email or posting it on the project Wiki at the beginning of every Sprint can build trust, regardless of the underlying contractual form, and make it easier to demonstrate the product during the sprint review.

The sprint contract can be referenced in the commercial contract. I have found that after a couple of releases, the commercial contract can wither down to a one-page Time & Materials agreement, maybe with a cost ceiling for the quarter or next major release.

Should you tie payment to how much scope is delivered in each sprint? This is a complicated question which I will discuss in Chapter 8, Recommendations.

The text is excerpted from Ten Contracts For Your Next Agile Project, by Peter Stevens.