Nine weeks, 150 points, and a proposal to lower the Definition of Done
Our product adjudicates dental claims for 40 clinics. The team is six Developers plus you as Product Owner, two-week Sprints, average velocity 28 points. A regulator has set a hard date nine weeks out: every automated claim decision must carry an immutable audit record, or the clinics lose the right to use the system. Your estimate of the remaining work is 150 points - about five Sprints. Nine weeks gives you four and a half. At the steering committee the programme manager proposes a 'release Definition of Done': code merged plus one manual test. No automated regression, no security review, no operations runbook - so the burn-up looks achievable. Your real Definition of Done requires all four. Two Developers say they can 'probably' shrink the estimate by reusing a logging library that has never run in production. The committee meets fortnightly and wants a green dashboard. Nobody has asked what happens if the audit record is wrong.
1. Who owns the Definition of Done, and what do you do with the programme manager's proposal?
Read the worked answer
Ownership. The Developers own the Definition of Done; if the organisation has a standard, all teams must use it as a minimum and no one may lower it for a release. It is not the Product Owner's to trade away, and it is certainly not the programme manager's. You cannot approve it, and you should not stay quiet while it is applied.
Why the proposal is worse than it looks. The moment items are marked Done without regression, security review and a runbook, the burn-up stops describing reality. For a regulated audit trail, 'one manual test' removes exactly the evidence the regulator will ask for. You would get a green dashboard and a system the clinics still cannot legally use - negative value, plus the cost of the work being redone under time pressure.
What you do:
- Refuse to report those items as Done in the Sprint Review. Done means it meets the Definition of Done, full stop.
- Restate the conflict correctly: it is a scope versus time problem, not a quality problem. Quality is the one variable that should not move; scope, date and people can.
- Put the numbers in front of the committee: 150 points at 24–32 points per Sprint is 108–144 points in four and a half Sprints. The forecast does not reach 150. Say that out loud, with the range.
- Bring options rather than a refusal - see the next question.
2. What options do you put in front of the steering committee, and how do you handle the 'probably' from the two Developers?
Read the worked answer
Frame it as four levers: scope, time, people, quality. Quality stays fixed.
- Option A - full Definition of Done, reduced scope (recommended). Audit records for the three highest-volume decision types by the regulatory date, covering roughly 85% of decisions, with the remaining four types four weeks later and a documented manual compensating control in the interim. Requires a conversation with the regulator now, not in week eight.
- Option B - full scope, later date. Seven Sprints, with the clinics moved to a manual process for the gap and a formal exception filed.
- Option C - full scope and date, add people. Warn that onboarding three Developers to a regulated codebase inside nine weeks usually slows delivery before it accelerates it.
- Do not offer Option D, 'lower the bar'. The compliance risk lands on the clinics and the agency, not on the dashboard.
On the logging library: 'probably' is an assumption, and a plan should not rest on an untested one. Timebox a two-day spike this Sprint with a production-representative load and a security read-through. If it holds, re-estimate and tell the committee the number moved and why. If it fails, the 150 stands. Logging is also the exact component an audit obligation depends on - a library nobody has run in production is the last place to take a shortcut.
Show the forecast as a range with the assumption list attached. A committee that sees only one number will treat it as a promise.
3. Suppose the committee chooses the shortcut anyway. What is your obligation as Product Owner?
Read the worked answer
Transparency, in writing, and no false Done.
- Do not mark items Done that do not meet the Definition of Done. The Increment is not releasable; say so at the Sprint Review, in the release decision record, and in the steering report. If the committee wants a different label for the dashboard, that is their report, not your backlog.
- Create the debt explicitly. Add backlog items for the skipped regression suite, security review and runbook, ordered by risk, with the regulatory exposure noted in the description. Undone work that is invisible is the only kind that compounds silently.
- Name who is accepting the risk. A compliance exception must be accepted by someone with the authority to accept it - the accountable business owner, in writing. A Product Owner is accountable for value, not for absorbing regulatory liability on a steering group's behalf.
- Protect the team from the consequences of the claim. They should not be asked to sign off work they know is incomplete, and the next Sprint should not pretend the debt does not exist.
Reasoning. The role's accountability is to maximise value. Shipping an unauditable adjudication system to forty clinics delivers the opposite: it burns nine weeks and leaves the clinics unable to use the product. Your job in that room is to make the trade-off legible, early, and attributed - not to make the chart green.