Agile Contracts: How to Estimate with Open Scope
Traditional software contracts have fixed scope, fixed timelines, and fixed prices. Agile contracts have variable scope, variable timelines, and variable prices. How do you reconcile the need for predictability with the reality of agile development?
The Problem with Fixed Contracts
Traditional contract: “We’ll deliver features A, B, C, D, and E for $100K by June 30.”
Problems:
- Scope A-E is unlikely to be 100% defined at signing time
- Changes are inevitable and expensive (contract amendments)
- The vendor bears all underestimation risk
- The client pays for features they may no longer need
Agile Contract Models
1. Per-Sprint Pricing (Time & Materials with Predictability)
How it works: The client pays per sprint, with a minimum commitment of N sprints.
Example:
- $15K per 2-week sprint
- Minimum commitment: 6 sprints ($90K)
- Scope defined sprint by sprint
- Client can cancel after minimum with 1 sprint notice
Advantages:
- Full scope flexibility
- Shared risk
- Client sees progress before paying for more
- Vendor has predictable revenue during the minimum commitment
When to use: Projects with initially unclear scope.
2. Minimum Scope + Options
How it works: A contract with guaranteed minimum scope plus options to add more.
Example:
- Minimum scope: features A, B, C → $60K
- Option 1: feature D → $15K
- Option 2: feature E → $25K
- Client decides each sprint whether to activate options
Advantages:
- Client knows the spending ceiling
- Vendor has guaranteed minimum scope
- Flexibility in prioritization
When to use: The client needs a pre-approved budget.
3. Target Cost
How it works: A target cost is estimated. If the team delivers under budget, savings are shared. If over budget, the overrun is shared.
Example:
- Target cost: $100K
- Delivered at $80K: $20K saved → 50/50 split between client and vendor
- Delivered at $120K: $20K overrun → 50/50 split
Advantages:
- Both parties are incentivized toward efficiency
- Truly shared risk
- Full transparency
When to use: Long-term relationships with mutual trust.
4. Value Delivered (Performance-Based)
How it works: Part of the payment is tied to outcome metrics.
Example:
- 70% of payment per sprint
- 30% tied to metrics: conversion, performance, satisfaction
When to use: When the client has clear, reliable business metrics.
Estimation for Agile Contracts
Estimation by Detail Level
| Level | Detail | Tolerance | Use |
|---|---|---|---|
| Proposal | Epic-level with T-shirt sizing | ±50% | Commercial proposal |
| Kickoff | Features with Planning Poker | ±30% | Initial contract |
| Sprint Planning | Stories with Planning Poker | ±15% | Execution |
Budget Range
Instead of a fixed price, offer a range:
“We estimate between $80K and $120K for the described scope. With real data after 3 sprints, we can refine to ±10%.”
Velocity as Currency
“Contract of 150 points at $20/point = $3,000K. Scope is the prioritized backlog. If the client changes priorities, the total cost doesn’t change.”
Essential Clauses
Scope Change
“Scope can be reprioritized at any time by the client. Items removed from the backlog return as credits. Added items are estimated and billed per agreed point price.”
Transparency
“Vendor provides real-time access to the board, velocity, and burndown chart.”
Acceptance Criteria
“Each sprint is accepted based on the agreed Definition of Done. Rejected sprints are redone at no additional cost.”
Exit
“After the minimum commitment, the client may terminate with 1 sprint notice. Code and intellectual property are transferred.”
Conclusion
Agile contracts are fairer than traditional ones because they acknowledge the uncertain nature of software development. The key is aligning expectations: per-sprint pricing for predictability, variable scope for flexibility, and full transparency for trust.