Definition of Done and the Challenge of Shared Expectations
A developer says a feature is finished. A tester is still waiting to validate it. Operations needs deployment instructions. The business expects something people can use. Everyone has been discussing the same work, but the word “done” has been carrying several different meanings.
A Definition of Done makes those expectations visible. Agreeing on it can be difficult, especially when a team is new, its work is varied, or its members have different professional backgrounds. My view is that the agreement becomes clearer as the team learns together. That learning needs to begin with an explicit standard that people can actually use.
Part one: The role of Definition of Done
What a Definition of Done achieves
A Definition of Done, usually shortened to DoD, describes the shared quality standard that completed work must meet. In a product team, it helps establish when a change can count as part of the finished product. Writing the code alone may leave testing, integration, or other necessary work outstanding. [4]
A useful definition should help the team in four practical ways:
- Make quality observable, so people can explain how the result was checked.
- Make remaining work visible, so a finished implementation does not hide unfinished verification or integration.
- Improve planning, by including the work needed to reach the agreed standard.
- Build trust, so stakeholders understand what they can rely on when the team reports completion.
The wording matters because vague criteria reproduce the original problem. “Properly tested” still leaves people to decide privately what “properly” means. A reference to an agreed set of checks, with accessible results, gives the team something it can examine together.
Its place in Agile
The Agile Manifesto’s principles emphasise frequent delivery of working software, technical excellence, collaboration, and regular improvement. They do not prescribe one universal Definition of Done template. An explicit completion standard supports those principles by helping people assess whether the work they describe as finished is usable and meets their quality expectations. [1]
Its formal role in Scrum
In Scrum, the Definition of Done is the commitment associated with the Increment: the usable product result created through the team’s work. It describes the quality conditions that result must meet.
The Scrum Team creates an appropriate definition when organisational standards do not already provide one. Any organisational definition is a minimum, and Developers are accountable for adhering to it. Teams working together on one product must share the same definition.
A Product Backlog item that does not meet the definition cannot contribute to the Increment, be released, or be presented at the Sprint Review. It goes back into the Product Backlog to be considered for future work. The Review itself is not a release gate; a usable Increment can be delivered earlier.
The definition applies throughout each Sprint. Quality must not decrease during a Sprint. Scrum identifies three accountabilities: Product Owner, Scrum Master, and Developers; project manager is not an additional Scrum accountability. These rules establish the framework within which the team develops its working agreement. [2]
How completion works in Kanban
The Kanban Guide describes a broader agreement called the Definition of Workflow. It includes the work items, their start and finish points, workflow states, control of work in progress, explicit movement policies, and a forecast of how long work should take.
A Definition of Done can express part of those policies, although Kanban does not require Scrum’s terminology. Completion needs a clear boundary: finishing development and finishing the whole workflow can mean different things. The chosen boundary also determines what cycle time measures.
For example, a workflow ending at “Ready for release” describes a different outcome from one ending at “Released”. Neither label should leave stakeholders guessing about what has happened. This is a practical application of making the workflow explicit.
Kanban does not require Sprints. Teams can apply and improve their policies continuously. When Kanban complements Scrum, it adds attention to flow while Scrum’s Definition of Done still governs the Increment. [3]
One shared standard with room for different requirements
This is where defining “done” can initially feel impossible. How can one definition cover a new feature, a defect fix, a documentation change, and an investigation?
A useful starting point is to separate three questions:
| Agreement | Question it answers | Example |
|---|---|---|
| Definition of Done | What quality standard must the completed product work meet? | Changes are integrated and the agreed checks pass. |
| Acceptance criteria | What must this particular item achieve? | A CSV export includes the selected filters and agreed columns. |
| Task completion conditions | When has this specific activity finished? | A reviewer has examined the proposed change and recorded findings. |
The common definition should remain concrete. Work items can then supply the details that vary. A documentation change and a code change may need different evidence, while both contribute to a product that must meet its agreed standard.
Likewise, completing an investigation can mean answering an agreed question and recording the findings. That is a useful result, but the completion of a research task alone does not establish that a usable product Increment exists. Being precise about the result prevents an internal task status from overstating progress.
When to establish and use the agreement
Establish a first usable definition early enough to guide the work, ideally before the team begins its first delivery Sprint. At Sprint Planning, use it to discuss what can realistically be completed, including verification, integration, and other required activities.
Carry that agreement across Sprints. There is no benefit in rewriting it simply because a new Sprint begins. Keep it visible during delivery, and use the Retrospective to examine where its wording, application, or supporting practices need improvement.
If the team changes the definition, explain what changed and how the change applies. Avoid discovering a new quality expectation only when somebody asks for the work to be accepted. Equally, avoid removing a requirement merely to make unfinished work appear complete.
Part two: Building shared understanding in a developing team
The room cleaning example
Imagine asking a child to clean their room.
The child puts the toys in a box and clears a path across the floor. They have done the work they understood you to be asking for. A few minutes later, they announce that the room is clean.
You walk in and see clothes on a chair, books scattered across the desk, and a cup left beside the bed. In your mind, a clean room included putting the clothes in the laundry basket, returning the books to the shelf, taking the cup to the kitchen, and wiping the desk.
Both people had a picture of the expected result. Those pictures were never compared.
Before the next attempt, you could agree on a few observable conditions: toys in their box, clothes in the basket, books on the shelf, the cup in the kitchen, and the desk clear and wiped. You could even look at an example together. The child now has a much clearer basis for deciding when the task is complete.
The comparison concerns hidden expectations. In a professional team, people bring different expertise and responsibilities to the same work. Each perspective may reveal something important that the others have not yet considered.
Why agreement is difficult at the beginning
A team forming a new working relationship has not yet built a shared history of what tends to go wrong. One person may assume peer review is obvious. Another may regard it as an extra activity. A colleague who has supported production systems may expect recovery instructions that nobody else has considered.
Varied work makes the problem harder. A generic phrase such as “completed to a good standard” seems to cover everything, but provides little help when people disagree. At the opposite extreme, a checklist written entirely around application code may make little sense for documentation or research.
Pressure can also discourage the conversation. Discussing quality takes time, and unresolved dependencies may make the desired standard difficult to achieve. The temptation is to mark the item complete and leave the remaining work for later.
I would describe maturity here as the team’s ability to make assumptions visible, agree on evidence, and respond honestly when the evidence is missing. Years together do not automatically produce that ability.
Bring the business into the conversation
The agreement needs to connect the team’s understanding with the expectations of the people who depend on its work. Involve the Product Owner and relevant stakeholders when identifying quality, usability, and operational needs. If a project manager coordinates dependencies or reporting, make sure they understand what the team’s completion status actually promises.
Ask the client or business representative what they expect to be able to do with the result. A request for a new report might mean “show the data on screen” to one person and “produce an export that finance can use without manual correction” to another. That difference should become part of the item’s requirements before completion is assessed.
Make any necessary approval explicit, including who gives it and what they examine. Do not leave “the business will approve it” as an undefined final step.
How to create a first working definition
I would start with a short workshop around real work. The following sequence gives the team something concrete to discuss.
- Choose a few completed items that later needed unexpected work. Include different types of work where possible. Ask what each person thought was finished and what remained.
- Separate recurring quality expectations from individual requirements. If an expectation applies across product changes, consider it for the common definition. If it describes one feature’s behaviour, record it with that item.
- Write observable conditions. Replace “tested” with an agreed description of which checks must pass and where the results can be found. Replace “documentation complete” with the information that must be current and who needs it.
- Test the draft against real examples. Walk through a feature, a defect fix, and a less typical item. Discuss what evidence would show that each criterion has been met. A condition that nobody can interpret consistently needs revision.
- Check the team’s ability to meet the standard. Missing access, environments, skills, or support are delivery problems to resolve. Make those constraints visible instead of hiding them behind a completion status.
- Use the definition and inspect the results. Record recurring misunderstandings and unexpected rework. Improve the agreement when those observations reveal a gap.
A short initial definition can work well if it covers the product’s essential quality needs. Simplicity should come from clear wording and deliberate scope. It should not depend on omitting necessary checks.
A practical example for a software team
Consider a team adding a CSV export to a reporting product. The item’s acceptance criteria could specify that the export respects the selected filters, includes the agreed columns, and handles an empty result clearly.
Alongside those requirements, the team could use the following shared Definition of Done. This is an illustrative starting point to adapt to the product and its risks:
- The agreed behaviour is verified, and evidence of the checks is available.
- The change has been reviewed and integrated into the product.
- The agreed regression checks pass, and unresolved defects do not breach the product’s defined quality thresholds.
- Applicable security, privacy, and accessibility requirements have been checked against the agreed product standards.
- Affected user guidance and operational information are current.
- The resulting Increment is usable and can be delivered without outstanding work required by this definition.
The export’s specific behaviour belongs to that feature. The shared quality expectations also apply when the next change is a defect fix or another feature.
Phrases such as “applicable” and “agreed checks” need supporting detail. Identify the relevant standards and test sets. Define in advance when a criterion applies and what evidence is needed; record the reason when it does not apply. Otherwise, flexible wording can become another source of private interpretations.
How the definition develops with maturity
Scrum Inc. describes the Definition of Done as an agreement that develops as the team matures, and warns against lowering it under deadline pressure. That supports an important part of the maturity argument: the standard should respond to what the team learns. [4]
Early improvements may be about clarity. Later improvements may come from stronger capabilities: automated checks, more reliable environments, clearer operational guidance, or better ways of testing integration.
For example, discovering that apparently complete changes repeatedly fail after deployment may prompt the team to add a relevant integration check and invest in an environment where it can run. The improvement requires both an expectation and the ability to satisfy it.
I would judge progress by whether the definition reduces surprises. Look for fewer items reopened because required work was missed, fewer late discoveries of missing checks, and fewer disagreements about what a completed result includes. These observations are signals for learning, rather than scores for ranking individuals.
A mature agreement may become more demanding without becoming much longer. Some details can live in clearly referenced standards and automated checks. What matters is whether people understand the conditions and can show that they have met them.
Completion still needs feedback
A product can meet its quality standard and still fail to solve the customer’s problem. A correctly implemented export may be difficult to find, contain information nobody needs, or support a workflow the business has already changed.
The Definition of Done gives the team a reliable basis for discussing the completed result. Customer feedback and evidence of actual use help determine whether that result delivers value. Both conversations matter, and neither should be hidden inside an ambiguous statement that “the customer is happy”.
Make expectations visible before work begins
The room-cleaning example shows how easy it is to finish work according to an expectation that other people never shared. A team can avoid much of that confusion by discussing the result early, recording the conditions that matter, and checking them consistently.
My view is that a useful Definition of Done develops through repeated conversations about real work. Start with an agreement people can use, learn from the places where it breaks down, and improve the capabilities that allow the team to meet it.
Before the next item begins, ask everyone involved: “What evidence would convince us that this is done?”