Definition of Done Practical Guide: When is code actually 'Done'?

Thomas 23 December 2025

This article is part of the Developer Survival Kit.

Practical solutions to win back your focus time and deliver real results instead of just playing along in the "Agile Theater."

"Is the ticket finished?" – "Yes, I just need to deploy it quickly and fix the tests."

Honestly: Then it's not finished.

In software development, "finished" is one of the most elastic terms ever. For one person, it means "the code compiles on my machine"; for another, it means "it runs scaled in the cloud and the documentation is up to date." When these definitions drift apart within a team, it creates friction, bugs, and – worst of all – technical debt that will break your neck months later.

The Definition of Done (DoD) is your most important tool for documenting this clearly for everyone on the team. According to the Scrum Guide 2020, it is not just a list, but a commitment to quality. It is the moment when a bit of code becomes a real increment.

The Crucial Difference: Acceptance Criteria vs. Definition of Done

Many teams throw Acceptance Criteria (AC) and the DoD into one pot. This is a strategic mistake.

Acceptance Criteria are specific to a single ticket. They describe the What (Example: "The user can pay with a credit card."). The Product Owner uses them to check if the functional requirement is met.

Definition of Done (DoD) is the global quality standard for every single ticket. It describes the How. (Example: "Documentation is done, no critical security vulnerabilities, peer review completed.").

The analogy: When you build a house, the acceptance criteria are the color of the walls and the number of rooms. The Definition of Done is the structural integrity, the fire safety regulations, and the electrical wiring. The buyer (PO) decides on the rooms, but you as the expert (Developer) decide that the house won't collapse.

Why "Works on my Machine" Doesn't Count

In Scrum, "Done" means that the increment is in a state where it could theoretically be released immediately. When work does not meet the DoD, it is often called "Undone Work." The problem: Undone Work is a hidden risk. It creates a false sense of security about progress. If you have three tickets at the end of the sprint that are "almost finished" but don't meet the DoD, you have delivered zero.

An increment is only "born" at the moment the ticket meets the DoD. Everything else is just a promise for the future that will resurface as a time-sink in the next sprint.

The Anatomy of a Robust DoD: Tests, Docs, CI/CD

A good DoD is not a paper tiger in Confluence, but a checklist you have in mind for every pull request. A good DoD usually consists of these four pillars (the bullet points are, of course, just examples).

Pillar 1: Technical Quality (Code Level)

Peer Review: At least one other dev has seen and approved the code.
Static Analysis: The code meets linting rules and doesn't violate other automated code quality tests.
No Hardcoding: Secrets are in the vault, configurations are stored in the environment.

Pillar 2: Verification (Test Level)

Unit Tests: New logic is covered by automated tests.
Integration Tests: Interfaces with other modules are working.
Regression: Existing functionality hasn't been broken.

Pillar 3: Documentation & Visibility

Code Documentation: Complex algorithms are explained in the code (not the "what," but the "why").
User Docs/Readme: If the operation changes, the README or the API documentation (Swagger/OpenAPI) is up to date.

Pillar 4: Deployment & Infrastructure

Build: The code builds cleanly in the CI/CD environment.
Environment: The feature is deployed to the staging or test environment.

How to Defend the DoD Against Management Pressure

This is where it gets political. Sooner or later, a PO or manager will say: "We don't have time for the full tests; we need to go live tomorrow. Can we ignore the DoD just this once?"

Your answer as a Developer: "We can release the feature tomorrow, but then it's officially 'Undone Work.' We are violating our quality standard and taking on technical debt. This means we must schedule time in the next sprint to pay back this debt, otherwise, we risk the stability of the entire product."

The DoD is your shield. It allows you to say "No" without appearing uncooperative. You aren't saying no to the feature; you are saying no to abandoning professionalism. If the team weakens the DoD, predictability drops, and management loses trust in your ability to deliver.

🛡️ Defending Quality: Your Argumentation Guide

When "fast" is supposed to be more important than "good," the only thing that helps is referencing professional standards. Here is how you react:

Someone says...	Your response as a Pro Dev
"Can't we skip the tests this time? We have to go live tomorrow."	"We can deliver the feature, but then we violate our DoD. We'd be consciously building up technical debt that we'll pay for with interest and compound interest in the next sprint. Who takes responsibility for the instability?"
"Why isn't the ticket Done yet? You've finished typing the code."	"Typing is only half the work. According to the DoD, the peer review and security scan are still missing. Without these steps, the risk of a production error is too high. 'Done' means safe and reliable for us."
"We can do the documentation after the release."	"Experience shows that never happens. Undocumented code is a technical risk. We're going to finish the job right now so the next person working on it (maybe myself in 3 months) doesn't have to guess."

Practical Checklist for Backend & Frontend Teams

So you don't have to start from scratch, here is a suggestion for a pragmatic DoD that you can copy directly into your Jira or PR templates.

For Backend Teams

Code meets team coding standards (Linting).
All unit tests pass locally and in the CI.
API changes are documented in Swagger/OpenAPI.
New database migrations are idempotent and tested.
Logging & Monitoring (metrics) implemented for new endpoints.
Peer review conducted by at least one senior.
Code is correctly committed to the version control system.
Correct user permissions are assigned.
The Boy Scout Rule: Leave code cleaner than you found it.

For Frontend Teams

Feature works in supported browsers.
Responsive design checked on mobile/tablet.
Accessibility (A11y): Basic screen reader compatibility checked.
Bundle size has not increased significantly without a valid reason.
E2E tests for the happy path are green.
UI components are updated in Storybook (if applicable).
Meaningful sample content is created.
Translations are tested.

Tip: Review the DoD Regularly

In our team, it has proven useful to review the DoD regularly. Every week, we grab two points from our DoD and read them out loud. We then consider why we have these points in our DoD and if they still fit us. If in doubt, we adjust the points or even delete them. New points can also emerge this way. The DoD is a living document for us.

Conclusion: Quality is not an "Add-on"

Having a Definition of Done is easy. Consistently following through with it when the house is on fire is true professionalism. If you start taking the DoD seriously, you might slow down at first, but you will never be haunted by "zombie bugs" from old sprints again.

Anyone who slacks on the DoD isn't producing software; they are producing technical debt. And as we all know: you'll pay the interest for that in the next sprint, after hours, or on the weekend.

What's Next?
A strong DoD is the goal. But how do you prepare the work so that you can even achieve this quality within the sprint?

🎯 Next Step: Backlog Refinement: Slicing Tickets Like a Pro
🏠 Back to Overview: The Agile Survival Kit for Developers

Did this guide help you?
Share it with your team or discuss it with me on Mastodon. Real feedback helps me make these contents even better for us devs!