The nine-month fixed-price contract with two definitions of done
Meridian Insurance signed a nine-month, fixed-price contract to replace its claims portal. The contract lists 340 numbered requirements and a penalty clause tied to late delivery. The Product Owner is a former project manager who reports 'percent complete' to the client's contract manager every Friday. The Scrum Team has eight people and works in two-week sprints. After six sprints, velocity has stabilised at about 38 story points, but the client counts only 92 requirements as complete, while the team counts 160 against its own Definition of Done, which includes automated tests and documentation. Three change requests are waiting, the client's contract manager has declined all four sprint review invitations, and the programme board now demands a Gantt chart. The team's test automation is two sprints behind, and two senior developers have asked to be moved. The CEO has publicly promised the board a November launch.
1. The client reports 92 of 340 requirements complete; the team reports 160 done. What is your assessment of percent-complete reporting in this situation, and what would you change?
Read the worked answer
Percent-complete against a requirement count is a predictive control that measures activity, not value, and here it is actively misleading. Three things explain the gap:
- The two sides use different Definitions of Done. The team's includes automated tests and documentation; the client appears to count a requirement only when it has passed its own acceptance cycle.
- A requirement is not a unit of equal size, so 92/340 says almost nothing about remaining effort or remaining value.
- Work discovered late - test debt, integration work, non-functional requirements - is invisible in the count.
The Agile response is not to argue about the number but to repair transparency. First, agree one Definition of Done with the client in writing, including the acceptance step the client needs. Second, replace percent-complete with a burn-up that shows scope, accepted increments, and a forecast range based on velocity (38 points, plus or minus the recent variance), with test debt shown as visible work. Third, use the sprint review to show working software rather than a status slide. Fourth, state the forecast honestly: if November is not achievable, say so with data, because a late surprise destroys trust more than an early warning. The PO owns this conversation; it should not be delegated to a delivery manager. Expect resistance, because the penalty clause makes the number political.
2. The client has declined every sprint review invitation and has three change requests waiting. How do you handle both?
Read the worked answer
The sprint review is the product's inspect-and-adapt event, so the client's absence removes the only regular opportunity to validate value. Treat the refusal as a symptom rather than a snub: the review has probably been run as a demo of user stories the client does not recognise, at a time that does not suit them, with no decision attached. Fix the event before escalating.
Rebuild the agenda around the client's outcomes - claims cycle time, error rate, call volume - rather than story points. Hold it at their site or on their calendar, keep it to 60 minutes, and end with two or three explicit decisions. The three change requests should be presented there with cost, risk, and value so the client can choose rather than receive a queue update. Invite the business owner of the claims process, not only the contract manager.
If the client still refuses after two cycles, escalate in writing with evidence: the decisions not being made, the assumptions being stacked up, and the risk to their own acceptance. Record those assumptions in the backlog. Do not let the change requests sit - a late change is an expensive change. Equally, do not treat the client's absence as permission to decide contractual scope unilaterally: the PO owns ordering, but the contract owner owns contractual scope, and confusing the two will end badly.
3. The programme board wants a Gantt chart and the CEO has promised November. What are your options for the fixed-price contract, and what do you recommend?
Read the worked answer
Fixed price, fixed scope, and fixed date is a triple constraint that empirical delivery cannot honour at this level of uncertainty. The penalty clause is already producing the wrong behaviour: the two competing completion counts, the test debt, the developers asking to leave. A Gantt chart would convert that uncertainty into false precision and would be wrong by sprint 8.
The realistic options, roughly in order of preference:
- Fixed budget and date, variable scope. Rank the 340 requirements by value, agree a Must-have set that fits the forecast for November, and move the remainder to a phase 2 or a re-baselined release. This preserves the relationship and delivers something usable.
- Fixed scope, re-baselined date and price. Joint re-estimation with the client using velocity and the agreed Definition of Done. Painful, but honest.
- Descope or terminate the remainder if the value no longer justifies the cost.
Recommendation: bring the burn-up, the Definition-of-Done gap, and the test debt to a joint session with the client's commercial owner and yours, and propose option 1 with an explicit trade-off slider. The PO does not sign the contract, but the PO must supply the forecast and refuse to endorse a date the data does not support. Protect quality as well: cutting tests to hit November buys a date and sells a liability.