Definition of Done: How to Stop Calling Work Finished When Testing Is Still Pending

Why this matters: “dev done, testing pending” is the sentence that quietly destroys a product. This is the note that kills that sentence. It is also the mechanism that makes test cases and documentation structurally unavoidable, which is the fix for the problem described in Test Case Strategy.

What it is

The Definition of Done is a single shared checklist that applies to all work, describing what must be true before anything can be called complete.

It answers:

Is this genuinely, professionally finished, or does it just appear to work on my machine?

Unlike Acceptance Criteria, which change for every Story, the Definition of Done is written once by the team and changes rarely. Criteria ask “is this behaviour correct”. Done asks “is this work complete”.

Unlike Definition of Ready, this one is an official Scrum commitment. The Scrum Guide defines it as the formal description of the state of the Increment when it meets the quality measures required for the product, and it is blunt about the consequence: work that does not meet the Definition of Done cannot be released, cannot be presented at the Sprint Review, and is not part of the Increment. It goes back to the backlog.

A starter checklist

Start small and honest. A checklist the team actually follows beats an aspirational one that gets ignored in week two.

Version 1, for a team that currently has nothing:

• Code written and works locally
• Acceptance criteria all pass
• Code reviewed by one other person
• Merged to the main branch
• No known critical or high severity defects
• Manual QA pass completed

Version 2, after a few sprints:

• Everything in version 1
• Unit tests written for new logic and passing
• Test cases written and linked to the Story
• Integration tests passing
• CI pipeline green
• Deployed to the test environment
• Logging added for the failure paths

Version 3, mature:

• Everything in version 2
• Automated regression test added to the suite
• Security checks passed for anything touching auth, money or personal data
• Performance acceptable under realistic data volume
• Monitoring and alerting in place for the new path
• Feature documented: behaviour, edge cases, owner
• Feature flag configured, rollback path known
• Release notes updated

The Scrum Guide explicitly allows a team’s quality practices to mature over time, and expects the definition to strengthen as they do. What it does not allow is the definition weakening because a deadline is close.

The rule that makes it real

A Story is Done or it is not Done. There is nothing in between.

No “90% done”. No “done except testing”. No “done, just needs the documentation”. If the checklist is not satisfied, the Story is not finished, it earns zero points, and it goes back to the backlog to be finished next sprint. Partial credit rules are covered in Velocity and Capacity.

This feels harsh for about two sprints. Then it starts doing something valuable: it makes you ask why so many Stories are ending the sprint unfinished. And the answer is always useful. Either the Stories are too big and need splitting per Writing User Stories, or scope was added mid sprint, which is Feedback and Scope Control, or you pulled in more than your actual velocity supports.

Allow partial credit and you lose all of that signal. The board looks green, the sprint looks successful, and the product quietly accumulates half finished features. That is precisely how a team ends up with a large product and almost no test coverage, without anyone ever deciding to skip testing.

Why this is the fix for missing test cases

The reason we have features with no test cases is not that anyone decided to skip them. It is that testing lived outside the definition of finished. So when the sprint got tight, the code shipped and the tests did not, and nothing in the process noticed.

Put “test cases written and linked to the Story” inside the Definition of Done and the pressure changes shape. Now a tight sprint does not produce untested features, it produces fewer features, which is visible, honest, and something a Product Owner can make a real decision about. You are trading scope instead of silently trading quality.

That is the whole trick: make quality non negotiable so that scope becomes the thing that flexes. Scope flexing is visible and discussable. Quality flexing is invisible until it is a crisis.

Keep it short enough to actually use

A Definition of Done with thirty items is a wish list. Nobody checks thirty items honestly. Aim for seven to twelve, written in plain language, and displayed somewhere the team sees it during the sprint, not buried in a wiki page.

If some item is genuinely not feasible for every Story, either drop it or write the exception explicitly. For example, “documentation updated” might apply to user facing changes only. Write that down rather than leaving the team to guess, because an ambiguous checklist item gets skipped by everybody while each person assumes somebody else handles it.

When you cannot meet it

Sometimes you truly cannot, for example a Story depends on a third party sandbox that is down, so integration tests cannot run.

The honest handling: the Story is not Done. Either it stays in progress, or you split off the part that is genuinely complete and carry the rest. What you must not do is mark it Done with a mental note to finish later, because that note is the thing that gets lost, and six months later nobody remembers that this feature was never fully tested. That forgetting is exactly the problem described in Feature Inventory and Ownership.

If exceptions are happening constantly, that is not a Story problem, it is a signal that your Definition of Done does not match your reality. Change it deliberately in a retrospective rather than eroding it silently, one urgent deadline at a time.

The three definitions together

The thing to hold in your head, expanded from Glossary:

Three gates. Our current process has none of them, which is why anything can enter a sprint at any time and anything can be called finished. Putting these three in place, one at a time, is most of what Adoption Plan is about.