Reading time: 10 min

Fixed Price and Agile: Fix the Epics, Flex the Requirements

Fixed-price contracts and Agile delivery can create an uncomfortable tension. The supplier wants cost certainty, while the customer assumes that their understanding of the solution will evolve.

A common response is to freeze all requirements at the start of the contract. This may feel safe, but it creates another risk: the team becomes committed to delivering what was specified rather than what is actually needed and what delivers value.

A better approach is:

• Fix the epics.
• Flex the requirements.

Use DSDM thinking

DSDM provides a useful principle for fixed-price Agile delivery: fix time, cost and quality, while allowing scope to vary.

The challenge is therefore not to eliminate change, but to decide at what level scope should be fixed.

A practical answer is to fix scope at epic level.

The epics describe the major capabilities that the supplier is expected to deliver. Together with the business outcomes, critical quality requirements, constraints and exclusions, they establish the contractual boundary.

For example:

Epic: Manage customer accounts

This epic forms part of the fixed contractual scope. The detailed requirements underneath it can evolve:

• Create an account
• Update customer details
• Manage communication preferences
• Suspend an account
• Reactivate a suspended account
• Close an account

As the team learns more, these requirements can be refined, decomposed, reprioritised, added or removed.

Use MoSCoW to create flexibility

Requirements within an epic will not all have the same priority. DSDM’s MoSCoW technique provides a useful mechanism:

• Must Have — essential for the solution, the project guarantees to deliver these,
• Should Have — mandatory, but not critical,
• Could Have — wanted or desirable, but less important (less impact if left out)
• Won’t Have this time — explicitly outside the current delivery

This flexibility matters in a fixed-price environment. If every requirement is a Must Have, there is effectively no room to respond to learning or unexpected complexity.

Allow scope trading within the epics

Suppose the team discovers that reactivating a suspended account matters more than expected, perhaps because customers are churning after a suspension rather than coming back. Rather than automatically raising a contract change, the Product Owner and supplier can trade scope within the epic. Reactivating a suspended account moves from Could Have to Must Have, and in exchange a lower-value reporting feature is scaled back or dropped. The epic stays the same, the commercial boundary stays the same, and only the detailed scope evolves.

Define when formal change control applies

The contract should clearly distinguish normal backlog evolution from a change to contractual scope.

• If a requirement changes within an agreed epic, it can normally be handled through backlog management.
• If the customer introduces a completely new epic, formal impact assessment may be needed.

For example, the agreed contractual epics might be:

• Manage customer accounts
• Manage orders
• Process payments
• Produce operational reports

Later, the business asks for another epic: Manage customer loyalty programme. This introduces a new capability outside the agreed epic boundary and may therefore require a contractual change.

A useful rule is:

• Change within an epic → manage through the backlog.
• Change to the agreed epics → assess as a potential contract change.

Acceptance should follow the same logic

Successful delivery should not mean completing every user story that existed when the contract was signed. Acceptance should focus on the agreed:

• epics;
• business outcomes;
• mandatory requirements;
• critical quality requirements;
• regulatory and other constraints.

Individual stories and detailed requirements can have their own acceptance criteria as they are refined and delivered.

Fixed price does not require fixed detailed requirements

A workable fixed-price Agile model could therefore be quite simple.

• Fixed: Price, delivery period, quality expectations, business outcomes, epics, critical constraints and scope boundaries.
• Flexible: Requirements within the epics, user stories, priorities, acceptance criteria and solution details.
• Controlled: MoSCoW prioritisation and scope trading provide flexibility while protecting the essential capabilities.
• Formal change: New epics or other changes that materially alter the agreed contractual boundary.

Fixed price does not have to mean freezing the entire requirements specification. Fix the epics. Flex the requirements. Let the backlog evolve as the team learns.