A Definition of Done Checklist for Software Teams, Written After Three Bad Sprints

Delivery confidence is a slower thing to lose than delivery speed, and harder to get back. Over three consecutive sprints, the defect rate rose. Not a spike in one release — a trend, which is the version that matters, because a spike is an accident and a trend is a system doing what it was built to do. [NEEDS INPUT: sprint length and team size for the squad with the rising defect rate] The people affected were not only the engineers rewriting their own work. Every stakeholder relying on a sprint commitment was quietly discounting it.

One bad sprint is noise. Two is worth watching. Three in a row is a measurement. The rate itself was the signal, and it was real because it survived the usual explanations — it did not track a single release, a single component, or a single stretch of overtime. It kept rising across sprints with different work in them. That is what separated it from the ordinary variance a delivery team lives with, and it is why I stopped treating it as bad luck.

I ran a root-cause review rather than a retrospective, because retrospectives collect opinions and I needed defects sorted by where they were introduced. The first suspect in any quality decline is people — a weak hire, an overloaded engineer, someone shipping fast and careless. I ruled that out early: a personnel problem concentrates, and it shows up as the same name repeating in the defect log. A rate that climbs across three sprints of different work is not concentrated; it is systemic.

The review pointed at two places. Test coverage had gaps, and acceptance criteria were unclear enough that two engineers could both be right about what a story required. [NEEDS INPUT: which test coverage gaps the root-cause review found most often] The other option I rejected was the obvious one: add QA capacity and lengthen the regression cycle. That catches more defects, but it catches them later, and it does nothing about the rate at which they are created. It buys a cleaner release at the cost of a slower one, permanently.

I moved the quality gate before the merge instead of after it, and I made the Definition of Done stricter than the bar the team had been clearing. Both choices cost throughput, and I said so before I made them. A pre-merge gate means work sits waiting on review and coverage instead of moving to done. A stricter Definition of Done means stories that used to close now stay open, so the burndown chart gets worse before the product gets better. I chose a visible drop in reported velocity over an invisible rise in rework, because rework was already being paid — just later, and by someone else.

The root-cause review came first, focused on test coverage gaps and acceptance criteria that left room for interpretation. What came out of it became the Definition of Done checklist: a story is not done because the code works, it is done when the stated conditions are met and demonstrable. [NEEDS INPUT: the specific items on the final Definition of Done checklist] Pre-merge quality gates enforced the parts a checklist alone cannot — nothing merges until the gate passes. Then I ran focused mentoring sessions on the recurring issue patterns the review had surfaced, because a gate that keeps rejecting the same mistake is a signal that nobody explained it.

Defect leakage dropped within two sprints. [NEEDS INPUT: defect rate before and after the pre-merge quality gates] Two sprints is the number I want people to notice, because it is short. The problem had taken three sprints to become visible and two to reverse, which tells you the defects were not hard to prevent — they were only easy to miss. The fix was a change to what the team agreed 'done' meant and where the check sat, not to who was on the team. [NEEDS INPUT: whether the pre-merge gate required new CI tooling]

The Definition of Done is not documentation. It is the only place a team agrees, in advance, what finished means — and when it is vague, every engineer resolves the ambiguity privately and differently. I now write acceptance criteria and the Definition of Done as one artifact, reviewed before a sprint starts rather than argued about at demo. The pre-merge gate stayed. So did the habit of reading defect rate as a trend line across sprints instead of a number per release.