Scrum with Fixed-Price Contracts: A Realistic Scenario

Fixed-price contracts and Scrum are often described as fundamentally incompatible. Fixed-price contracts define scope, schedule, and cost in advance and hold the contractor to those commitments. Scrum embraces change, defers detailed specification, and treats the product backlog as a living document. Put them together, and you have a structural tension that needs to be managed deliberately -- or it will manage you.

This is the story of how one government IT department tried to do exactly that -- and what they learned.

The Situation

A provincial government ministry awarded a fixed-price contract to a software development firm for the delivery of a case management system for social services staff. The contract value was $2.4 million. The scope was defined in a statement of work written over three months of business analysis. The delivery timeline was 18 months. The contract required delivery in two phases: a minimum viable product at month nine and a full system at month eighteen.

The software firm proposed using Scrum. The ministry's procurement and legal teams had concerns: if the scope is fixed and the price is fixed, how do we manage change? If the team is doing two-week Sprints, who decides what goes into each Sprint? What happens if the contractor finishes the fixed scope in month fourteen but it does not actually meet the need?

These were the right questions. The resolution they reached is instructive.

What They Did

The parties negotiated a set of mechanisms that allowed Scrum to operate within the fixed-price structure:

• Time-boxed scope with a change envelope: The statement of work defined the scope in terms of functional outcomes -- the system must do X -- rather than specifying implementation in detail. A 10% change envelope was built into the contract: up to 10% of the contracted scope could be swapped in or out through a lightweight Sprint-level change process, without requiring a formal contract amendment.

• Sprint-level change control process: At the end of each Sprint, the ministry's product owner could accept, defer, or flag a requirement for scope substitution. If the product owner wanted to add a new requirement, they had to identify a lower-priority item of equivalent size to defer. This kept the contract value stable while allowing the backlog to evolve.

• Quarterly scope reviews: Every three months, the steering committee reviewed the product backlog in its current state, confirmed alignment with the ministry's evolving needs, and made any scope adjustments that exceeded the Sprint-level change envelope. Significant scope additions required a formal contract amendment and additional compensation to the contractor.

• Definition of Done aligned to contract acceptance: The contract defined acceptance criteria for each major functional area. A feature was not considered delivered -- and did not trigger the associated payment milestone -- until it passed user acceptance testing against those criteria.

What Worked and What Was Hard

What worked: The early delivery of high-value features at month nine was a genuine success. Because the Scrum team prioritised the most critical workflows first, the MVP gave social services staff a working tool six months before the full system was delivered. Staff were using the system before it was complete, and their feedback improved the second phase significantly.

Stakeholder engagement improved across the project. The Sprint Review cadence gave ministry staff a consistent window to see progress, ask questions, and provide input -- something they had never had on previous waterfall projects.

What was hard: Contract amendments were slow. When the quarterly scope review identified a need that exceeded the change envelope, the formal contract amendment process took four to six weeks. During that time, the team had to continue working on agreed backlog items even if those items were lower priority than the new requirement.

Sponsor expectations required ongoing management. The ministry's executive sponsor had difficulty with the idea that the product backlog would evolve. She had expected the system to be built exactly as specified in the statement of work. Explaining that the Sprint-level adjustments were making the system better, not undermining the contract, required persistent communication from the project manager and the contractor's delivery lead.

Lessons for Others

• Define scope as outcomes, not implementations, wherever the contract allows. Fixed-price contracts with outcome-based scope are far more compatible with Scrum than contracts that specify implementation in detail.

• Negotiate a change envelope into the contract before award. Trying to add flexibility after the contract is signed is much harder. Build the mechanism in from the start.

• Invest in the product owner role on the client side. The ministry's product owner was the single most important factor in making the arrangement work. She understood both the business need and the Scrum process well enough to make real-time decisions at Sprint Reviews. Without that, the process would have stalled.

• Plan for amendment lag time. If your quarterly reviews may result in scope changes requiring formal amendments, build lag time into your schedule. The team needs work to do while the amendment is being processed.

Navigating Scrum in a fixed-price government contract environment requires experience on both the procurement and delivery sides. XNM's program and project delivery team has supported public-sector clients through complex agile delivery arrangements, including contract structuring, Scrum coaching, and contract management throughout delivery.