Agile Contract Design: Fix the Goal, Not the Scope
A traditional contract fixes the scope and then argues about every change. An agile contract fixes the goal, the budget limit and the way decisions are made, and leaves the detailed scope open. This guide explains when that makes sense, compares the main contract models, lists clauses that let you change course without a dispute, shows a made-up fixed-price versus capped-cost example with the math, and ends with how the same ideas apply to supply chain contracts. It is general education, not legal advice. Procurement rules differ by country and organization, so have a lawyer review any real contract.
The short answer
Design the contract around outcomes and control, not around a frozen list of features. State the business objective, set a spending ceiling, work in short increments, and agree how priorities will change and who decides.
Agile contracts shift some risk to the buyer, because the supplier no longer promises a fixed deliverable for a fixed price. The buyer gets flexibility and earlier evidence in return. Good clauses and an involved product owner are what make that trade safe.
Why a fixed scope breaks down
A fixed-scope, fixed-price contract works when the work is well understood: the same building, the same report, the same standard part. It struggles when the right answer is discovered during the work, as in software and many service projects.
- Requirements change. Users learn what they need by seeing something working.
- Suppliers price the risk. When scope is uncertain, bids include a cushion for the unknown.
- Change becomes a fight. Every new idea needs a change order, and each side protects its margin. Our guide to preventing contract scope creep covers the traditional side of this.
- Delivery is late. If the buyer sees results only at the end, misunderstandings surface when they are most expensive.
Contract models compared
There is no single agile contract. These are the common patterns, and many deals combine them.
| Model | How it works | Who carries the risk | Fits when |
|---|---|---|---|
| Fixed price, fixed scope | One price for a defined list | Supplier carries cost risk; buyer carries the risk that the list is wrong | Scope is clear and stable |
| Time and materials (with a cap) | Pay for time spent, up to a ceiling | Buyer carries effort risk; the cap limits it | Scope is uncertain; buyer can steer closely |
| Capacity or team-based | Pay for a stable team per month; the buyer sets priorities | Buyer carries scope risk; supplier carries staffing and quality risk | Long-running product work |
| Phased or modular | Separate, smaller commitments for each increment, with a decision before the next | Shared; each increment limits exposure | Large programs with unclear end state |
| Fixed price per increment | Price each sprint or release when its content is agreed | Shared | Moderate uncertainty; trust is building |
| Target cost with shared gain or pain | Agree a target; split savings or overruns by formula | Shared by design | Both sides want aligned incentives |
Neither extreme is always right. The more uncertain the scope, the more it makes sense to move down the table. The more the buyer has to hand over and not steer, the more it makes sense to move up.
A clause toolbox
These ideas appear in many agile-style agreements. They are illustrations, not model wording.
| Topic | What to agree |
|---|---|
| Objectives | The business outcome and how success will be judged, in place of a full feature list |
| Backlog | A prioritized list kept by the product owner, stated to be illustrative, not a required task list |
| Decision rights | Who prioritizes, who accepts work, and how fast they must respond |
| Cadence | Length of each increment, demos, and a review at the end of each |
| Definition of done | Working, tested, documented and secure, so each increment is usable |
| Budget ceiling | A cap on total spend and a rule for what happens when it is approached |
| Change within the ceiling | Scope can be swapped, added or removed without a formal amendment if it stays within the cap |
| Exit | Right to end after any increment, with a short notice, and clear handover of work |
| Key people | Named key staff and notice before replacing them |
| Ownership and access | Who owns the work product, and the buyer’s access to code, files and data during the work |
| Transparency | Shared access to the task board, metrics and costs to date |
| Disputes | A fast escalation path for disagreements about whether work is done |
A statement of work is still useful, though it may be framed as objectives. See our guide to what a statement of work is. The management side is covered in contract lifecycle management.
What government guidance suggests
Public buyers have written some of the most detailed guidance. The U.S. General Services Administration’s 18F team published an agile software development solicitation guide. It is written for U.S. federal software purchases and reflects one team’s view, so treat it as an example. Among its points:
- Use a labor-hour arrangement in preference to firm fixed price, because the buyer is buying developers’ time and not a defined product. Time and materials is an acceptable alternative, with a ceiling on total spending.
- Use a statement of objectives, not a statement of work, because the full scope cannot be defined up front.
- Keep the base period short, roughly 6 to 12 months, with a few short extension options, and keep the total under about three years.
- Attach the product backlog, but say it only illustrates anticipated work.
- At the end of each sprint, require code that is complete, tested, deployed, documented and secure.
A related idea is modular contracting. MITRE’s page on modular contracting describes buying IT systems in “successive, interoperable increments” to reduce risk. It cites FAR Subparts 39.002 and 39.103 and says each increment should be manageable on its own and deliver a working solution without relying on later increments. The page does not mention agile by name, so the link to agile delivery is our reading. For the delivery side, see our guide to agile in government.
A made-up example: fixed price vs capped cost
All figures are invented. A company wants a customer portal with 10 features. A supplier quotes a fixed price of $40,000 per feature, so $400,000. After the first month of work, user testing shows that 3 planned features are not needed, and 2 new ones are. The supplier prices new work at $50,000 a feature because it was not in the original bid.
| Fixed price with change orders | Capped time and materials | |
|---|---|---|
| Setup | $400,000 for 10 named features | Team of 5 at $12,000 each per month = $60,000 a month; 6 months; cap $400,000 |
| The change | Credit 3 features at $40,000 = −$120,000; add 2 at $50,000 = +$100,000 | Product owner re-prioritizes; no amendment needed within the cap |
| Cost after the change | $400,000 − $120,000 + $100,000 = $380,000 | $60,000 × 6 = $360,000 (and less if the work finishes sooner) |
| Process | Negotiate and sign a change order; credit may be disputed | Decide at the next planning session |
| Main risk | Paying a premium for change; arguing over credits | The team may take longer than expected; the buyer must manage closely |
On these assumptions the capped arrangement is $20,000 cheaper ($380,000 − $360,000) and simpler. But the numbers are not the lesson. If the team is slow or the product owner is absent, the time-based model can cost the full $400,000 cap and deliver less. The fixed-price model protects the buyer from that, at the price of rigidity. Which is better depends on how well you can steer and how much the scope is likely to move.
Choosing a supplier
Because the contract no longer fixes the deliverable, the supplier’s way of working matters more. The 18F guide, for example, suggests weighting the evaluation toward the proposed technical approach and past performance, keeping proposals short, and asking to see examples of past work and to interview key staff. Ideas worth borrowing:
- Ask for a short plan for the first increment, not a long proposal.
- Review examples of similar work and speak to references.
- Meet the people who will do the work, not only the sales team.
- Run a small paid trial before a large commitment.
- Check how the supplier handles disagreement and bad news.
The supply chain version
The same principle applies outside software: when demand or specifications are uncertain, build flexibility into the agreement instead of fighting about changes later. Common patterns in supply contracts (general practice, not drawn from a single source) include:
- Volume bands. Agree a base volume with a tolerance, such as plus or minus 20%, and a pricing rule inside and outside the band. For a base of 10,000 units a month, the band is 8,000 to 12,000.
- Rolling forecasts with a firm window. Share a forecast every period, with the nearest weeks locked and later weeks adjustable.
- Framework agreements with call-off orders. Agree prices and terms once, then order as needed.
- Price review triggers. Reopen price when a defined input cost moves by more than an agreed percentage.
- Substitution and second-source rules. Agree in advance how alternative materials or sites are approved.
- Shared measures. Agree a small set of delivery and quality measures, reviewed regularly together.
Flexibility has a cost, and suppliers may charge for it. A band that is too wide can raise prices, and one that is too narrow brings back change disputes. Test the numbers with both sides.
Common mistakes
- Calling a loose contract agile. Without ceilings, review points and exit rights, you have an open-ended commitment.
- No empowered product owner. The buyer must make decisions quickly. If not, the supplier waits and the clock runs.
- Mixing fixed price with constant change. It creates change-order friction.
- No definition of done. Arguments about whether work is finished follow.
- Forgetting the exit. Make it easy to stop after any increment.
- Skipping legal and procurement review. Some rules limit contract types, so involve them early.
Learn more
If you want structured study of contract drafting and administration, online providers such as Coursera and Udemy list contract management courses. We may earn a commission if you sign up, at no cost to you. We are not affiliated with any university. Look for coverage of contract types and change control. See also our overview of agile and our guide to contract management programs.
Frequently asked questions
What is an agile contract?
A contract that fixes the objective, budget limit and decision process, and leaves detailed scope open so priorities can change during the work.
How do you write an agile contract?
State objectives instead of a full feature list, set a spending ceiling, work in short increments with reviews, define done, name decision makers, allow scope changes within the ceiling and keep an easy exit.
Can an agile contract be fixed price?
Yes, in forms such as a fixed price per increment or a fixed price for a time-boxed team. A fixed price for a fixed, detailed scope that also changes often tends to create change-order friction.
Is time and materials the same as agile?
No. Time and materials is a pricing method. It suits agile work because scope can flex, but it needs a cap and close buyer oversight.
What is modular contracting?
Buying a system in successive increments, each of which works on its own, so that later increments can reflect changes in technology or needs.
What are the risks of an agile contract?
Cost can grow if the buyer does not steer, delivery can drift without clear acceptance rules, and some public buyers face rules that limit contract types. Ceilings, reviews and exit rights reduce these risks.
Does agile contracting work in supply chains?
The principle does. Tools such as volume bands, rolling forecasts, framework agreements and price review triggers allow change without constant renegotiation.
Browse certificate, course and degree programs side by side.