A 340-page fixed-scope contract with a three-hour monthly feedback loop
Your agency signed a fixed-price, fixed-scope contract for a case-management system. The requirements document is 340 pages and 14 months old, and any change must go through a change board that meets monthly with a six-week lead time. The vendor's nine-person team runs two-week Sprints and does produce an Increment every Sprint against its own Definition of Done. You are the agency's Product Owner. Your subject-matter experts are available three hours a month for review; nobody else on the agency side has seen working software. After three Sprints the vendor demonstrated 'Done' screens and the SMEs said the approval flow was wrong - a complaint that now appears in 40 queued change requests. The vendor's Scrum Master has started calling the Sprint Review a status meeting and cancels it when the SMEs are busy. The steering group's success measure is 'percentage of the 340 requirements signed off'.
1. The agile principles favour customer collaboration over contract negotiation. What does that mean concretely here, given the contract is not going away?
Read the worked answer
The principle does not say ignore the contract. It says a shared understanding of value, refreshed often, beats a document that encodes what someone believed fourteen months ago - and this contract is a case study in why.
The real defect is the feedback loop, not the clause. Three hours a month of SME time, delivered after items are already Done, is a machine for producing change requests. Forty of them is the invoice for that design.
Concrete moves:
- Move SME contact upstream into refinement. Two hours a week with one SME beats three hours a month with all of them. Acceptance criteria get agreed before development, not after.
- Make the Sprint Review a working session. SMEs drive the software through a real case; the vendor watches. No slides. That is collaboration, and it is also the cheapest defect detection available.
- Plan around the change board instead of fighting it. Cluster the 40 requests into themes, rank them, and submit one batched request per cycle containing only the highest-value changes. Forty individual requests will take forty cycles; three themes will take three.
- Fix the input, not just the throughput. You are the single voice for the agency. The 40 change requests are a sign that clarification is being relayed rather than owned - that is your accountability to close, not the board's.
- Use any tolerance in the contract. Many fixed-price contracts carry a scope-exchange allowance; find out before assuming every change costs six weeks.
2. The Sprint Review keeps being cancelled and success is measured as 'percentage of requirements signed off'. How do you handle both?
Read the worked answer
The cancelled review. The Sprint Review exists to inspect the Increment and adapt the Product Backlog; it is the Product Owner's main feedback instrument and the agency's only window into working software. A Scrum Master cancelling it because stakeholders are busy converts a governance failure into a scheduling habit. If SMEs cannot attend, the escalation is to the steering group, not a quiet cancellation. Options: shorten it to 45 minutes, hold it at the SMEs' location, or record the walkthrough - but never skip the inspection.
The sign-off metric. Percentage of requirements signed off measures documents, not outcomes. It rewards producing the wrong system faster, and it is trivially gamed: a requirement can be signed off against a screen nobody can use. It also gives the steering group no signal about the thing they actually care about - whether caseworkers can process a case.
Propose replacements, do not just criticise:
- Cases processed end-to-end in the current Increment, by a real caseworker.
- Percentage of backlog items with acceptance criteria agreed by SMEs before development started.
- Average days from SME feedback to a decision on the backlog.
- Change requests raised per Sprint - as a falling trend, this is the health metric for the whole arrangement.
Keep the contractual sign-off as an obligation, but stop using it as the steering measure. Bring the new set to the next steering meeting with one Sprint of baseline data behind it.
3. The vendor says every change costs extra and takes six weeks. How do you reduce the cost of change without breaching the contract?
Read the worked answer
The cost of change is driven mostly by when the change is discovered, not by the clause that processes it. A change found in refinement costs a conversation; the same change found after three Sprints of 'Done' costs a change request, a re-estimate, and six weeks.
Reduce the volume of formal change:
- Agree acceptance criteria with SMEs before development. Every criterion agreed early is a change request that never happens.
- Break the 340 requirements into small items with examples, and refine the top two Sprints only. You cannot pre-specify the bottom of a two-year list usefully.
- Validate at the Sprint Review before raising anything formally. Most 'changes' are misunderstandings that a working session resolves in ten minutes.
- Cluster and batch what remains into monthly submissions, ranked by value.
Reduce the cost of the changes that do happen:
- Negotiate a scope-exchange tolerance at the next contract review - an agreed percentage of effort that can be swapped without a board hearing.
- Ask the vendor what makes their change pricing high: unfamiliar code, missing tests, approval latency. Some of it is within their control and some is within yours.
Measure it. Track change requests per Sprint and days from feedback to decision. If those fall while the sign-off percentage holds, you have bought back real capacity without touching the contract's wording - and you have the evidence to renegotiate it later.