Skip to main content

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. 


You can get the whole book now, or you can read it a chapter at a time as I publish it here under the label ten contracts. To download the e-book or pre-order the physical book visit https://saat-network.ch/ten


Comments

Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…