When "Done" is not releasable
A ten-person team building a public-facing booking engine has a Definition of Done that lists code review, unit tests and deployment to staging. Load testing, accessibility checks and security scanning happen in a separate "hardening Sprint" every fourth Sprint, run by a different team. Product Backlog items are marked Done at Sprint Review once demonstrated on staging. The last two releases each required six weeks of hardening, during which defects found in load testing were fixed by the development team while the hardening team waited. Stakeholders at Sprint Review see demos of features that later change significantly. The Product Owner wants to keep the hardening Sprint because "the auditors need one release per quarter", and the CTO has asked why lead time from "Done" to production is nine weeks. The team's velocity looks strong at 85 points per Sprint, the highest in the department, and managers use it as a benchmark.
1. What follows from a Definition of Done that excludes load, accessibility and security checks? Who owns fixing it, and what does fixing it cost?
Read the worked answer
The Definition of Done is the team's shared understanding of what complete means, and its purpose is to guarantee that the Increment is in a usable, releasable state. Strip out load, accessibility and security verification and the word "Done" becomes false:
- Items marked Done are not releasable, so the Increment does not meet the definition of an Increment.
- Transparency is broken. The Sprint Review shows stakeholders something that is not actually finished, which is why features "later change significantly" - that is rework being discovered in public.
- Velocity of 85 points is inflated, because it counts work whose riskiest verification has not happened.
- Forecasting is unreliable: the six weeks of hardening is work that was always in the system, just not measured.
Ownership: the Development Team creates and owns the Definition of Done; the organisation can set a minimum standard (for example, mandatory security scanning) that no team may go below. The Product Owner must be part of the conversation because strengthening it visibly reduces velocity.
The fix is incremental, not a big-bang. Add one check at a time, automate it into the pipeline so it becomes cheap, bring the specialist skills needed into the team, and communicate in advance that velocity will drop and that the drop is a correction, not a decline.
2. The CTO asks why lead time from "Done" to production is nine weeks. What is your answer, and what should happen to the hardening Sprint?
Read the worked answer
The answer is that the clock is being started in the wrong place. Nine weeks after "Done" is nine weeks of deferred verification and rework - work that was always part of delivering those items. Lead time should be measured from when work is committed into a Sprint, and it will be far worse than nine weeks. The causes are batch size (four Sprints of risk accumulating before any load or security testing) and verification deferred outside the team, plus a handoff to a separate hardening team that creates queues on both sides.
On the hardening Sprint, avoid two lazy answers. Keeping it as-is institutionalises undone work and a false velocity. Abolishing it next Sprint without capability in place would just move the risk into production.
What I would propose:
- Shift verification left, one check at a time, into the Definition of Done and into the automated pipeline, so that load, security and accessibility are continuous rather than events.
- Attack batch size. Release more often from whatever Increment is compliant; four Sprints of accumulated change is why hardening takes six weeks.
- Address the skills and handoff. Either embed the hardening specialists into the development teams or turn hardening into an internal service with a published, short turnaround and a definition of what "ready for hardening" means.
- Set an exit plan and a metric - for example, the proportion of verification that is automated and the trend in post-Done rework - so the hardening Sprint is a temporary risk control with a date, not a permanent phase.
Finally, separate the auditor constraint from the engineering one: releasing quarterly is a business decision; being releasable every Sprint is the engineering standard.
3. Managers use the team's 85 points per Sprint as a department benchmark. How do you respond, and how does it interact with the Definition of Done change?
Read the worked answer
Push back clearly, because the benchmark is both invalid and actively harmful here. Story points are relative estimates calibrated inside one team; 85 points from a ten-person team with a weak Definition of Done is not comparable to another team's number, and the comparison rewards exactly the behaviour that created the problem. A team whose "Done" excludes load and security testing will always look faster than a team whose "Done" includes them.
The interaction is the important part. If managers benchmark on velocity, the team will resist strengthening the Definition of Done, because doing so will visibly cut points per Sprint. That makes the metric an obstacle to the very improvement the CTO is asking for.
What I would offer instead:
- Each team's own trend over time, used for its own forecasting.
- Flow measures: lead time from commitment to production, throughput of items, work-in-progress ageing.
- Quality and outcome measures: escaped defects, post-Done rework, incident rate, and whatever business measure the booking engine exists to move.
And I would pre-empt the drop: tell leadership now that when load and security checks move into the Definition of Done, reported velocity will fall, and that the fall is the correction of a measurement error rather than a loss of productivity. Better to say it before the number moves than to defend it afterwards.