Managing fixed-price projects in agile comes down to being clear about what is settled before work starts and what is left open. The price, the outcomes the software must deliver and the checks it must pass are agreed in writing first. The order of the work, the detail of each screen and the choice of which changes to make stay flexible. What does not work is a fixed price attached to a scope nobody has written down.
This article is about how to run such a project. Whether a fixed price is the right way to buy the work at all is a separate question, covered in our article on when fixed-price software development works.
Why agile and a fixed price appear to conflict
Agile is a way of building software in short cycles. At the end of each cycle the people who will use the software see a working part of it, and the plan is adjusted in response. The Agile Manifesto, the 2001 statement the approach takes its name from, values “customer collaboration over contract negotiation” and “responding to change over following a plan”. A fixed price depends on a contract and a plan, so the two look opposed.
The conflict is narrower than it looks. The manifesto itself says there is value in the contract and the plan, only less than in the collaboration and the response to change. The two ideas also answer different questions. Agile describes how the work is done and how feedback is used. A fixed price settles who pays if the work takes longer than expected.
The real tension is over change. Under time and materials, a new request is simply the next piece of work, because the buyer pays for it. Under a fixed price, change has to follow a rule both sides agreed in advance.
What is fixed and what stays flexible
| Element | Agreed before work starts | Decided during the build |
|---|---|---|
| Price | A fixed sum for the written scope | Moves only if you accept a quoted addition |
| Scope | A list of outcomes, each sized by the supplier | The detail of screens and steps within each outcome |
| Order of work | Which outcomes matter most | The running order, reviewed every cycle |
| Acceptance | The checks each outcome must pass | Sign-off of each item as it is finished |
| Change | The rule: swap, add or defer | Which changes are worth making |
Before the build: write the scope as outcomes
Agile teams describe work as user stories: short statements of what one kind of user needs to do, such as “a customer can see the progress of their order without telephoning”. The full set of stories, in order of importance, is called the backlog.
On a fixed-price project the backlog is the scope, and it has to be complete enough to price.
- Every outcome is listed. The detail of a screen can wait. The existence of the outcome cannot.
- Each outcome has acceptance checks. These are observable statements of what must be true for it to count as finished.
- Each outcome is sized by the supplier, so that one item can later be compared with another.
- The unknowns are investigated first. The condition of existing data and access to the systems to be connected can both change the amount of work.
- Assumptions and exclusions are written down.
This stage is often called discovery, and a careful supplier may charge for it separately. Our project planning worksheet covers what to prepare on your side.
Many agile teams size work in story points, a relative measure that has meaning only inside that team. Points help a supplier plan. They make a poor unit for a contract, because a buyer cannot check them. Hold the supplier to the listed outcomes and their acceptance checks.
During the build: short cycles and regular reviews
Once the price is set, the project runs much as any agile project does.
Work is done in short cycles. Scrum, a widely used agile method, calls them sprints, and its guide limits a sprint to one month or less. Two weeks is a common choice.
Each cycle ends with a review of working software. You see the software itself, not a status report, and say whether it does what the outcome described. A misunderstanding surfaces within weeks, while it is cheap to correct, and items can be signed off as they are finished so that acceptance is not left as one large test at the end.
One person on your side can decide. Scrum calls the person who sets priorities the product owner. On a project built by a supplier, that responsibility has to sit with someone in your business who knows how the work is done and has the authority to choose.
The most important work comes first. Order the list so that the outcomes the business depends on most are built and reviewed early. If one of them proves harder than expected, everyone finds out while there is still room to respond.
Clarification is not change. Deciding how a screen is laid out or what a message says is detail within an agreed outcome, and is covered by the price. A change adds an outcome or alters an acceptance check. Agree that line at the start, with an example or two.
Handling change: swap, add or defer
New requests will come, because seeing working software is what prompts them. Each one is assessed by the supplier and then handled in one of three ways, and the choice is yours.
- Swap. The new item replaces one of similar size that has not been started, and the price stays the same. This is what keeps a fixed-price project agile.
- Add. The item is quoted and added to the scope at that price. Nothing goes on the bill without your agreement.
- Defer. The item goes on a list for a later phase.
Swaps need a few rules. The supplier sizes both items and explains the comparison. Only work that has not begun can be swapped out. A change that disturbs what is already built, such as a new way of structuring the data, costs more than its size suggests. Each swap is recorded in writing, so that the scope at the end is the one the acceptance checks are run against.
Some suppliers offer a different arrangement under a similar name: the budget and the end date are fixed, and the scope is allowed to vary. It usually relies on MoSCoW prioritisation, which sorts requirements into Must have, Should have, Could have and Won’t have this time. It comes from DSDM, an agile method that fixes time and cost and negotiates features. Only the Must haves are guaranteed, and the Agile Business Consortium’s DSDM guidance recommends that they make up typically no more than 60% of the effort. This is a legitimate way to run a project, but it commits the supplier to less: you carry the risk that the Should and Could items are never delivered. Under a fixed price for a fixed scope, the supplier carries the risk of an overrun on everything that was agreed.
Questions to ask before you start
Fixed-price agile projects tend to fail for a small number of reasons, and each can be tested with a question before you sign.
- What exactly is fixed: the scope, or only the budget? The answer tells you who carries the risk.
- How will the scope be written down, and what checks will each item have to pass? “We are agile, so we do not write specifications” is a reason to look elsewhere.
- How often will we see working software, and who should attend from our side?
- How is a swap sized, and who decides what counts as similar?
- Where is the line between a clarification and a change? Ask for an example of each.
- Who on our side needs to be available, and for how many hours a week?
CodeFirst builds to a fixed price on this pattern: the scope, the price and the acceptance checks are agreed first, you see working software during the build, and anything new is quoted. Our fixed-price page sets out the steps. If the outcomes of a project cannot yet be listed, a fixed price is the wrong tool, and our comparison of fixed price and time and materials explains the alternatives.