Definition of Done | Agile & Scrum Exercises

1 / 5

A junior developer asks during backlog refinement:

"What's the difference between the Definition of Done and acceptance criteria? They both seem to describe when a story is finished."

Which response correctly explains the distinction?

The Definition of Done (DoD) and acceptance criteria serve different purposes and operate at different levels:

Concept	Scope	Who defines it	Example
Definition of Done	Every story, every sprint	The whole Scrum Team	"All unit tests passing, code reviewed, deployed to staging"
Acceptance criteria	This specific story only	Product Owner + team	"Given the user enters an invalid email, When they submit the form, Then an inline error is shown"

A story is truly done only when it satisfies both its acceptance criteria (it does the right thing) and the Definition of Done (it meets the team's shared quality standard). This is why engineers say "done done" — functionally complete is not the same as DoD-compliant.

2 / 5

During the sprint review, a developer presents a feature and says:

"This one is done done. It passed all acceptance criteria, all tests are green, the code was reviewed by two people, and it's already deployed to staging."

What does the phrase "done done" specifically communicate in Scrum?

The phrase "done done" emerged in Agile teams to distinguish between two very different states:

State	Meaning	Example
"Done" (first done)	Developer's personal assessment: "I finished coding it"	Feature works locally; not yet reviewed or tested
"Done done"	Fully satisfies the team's Definition of Done	Tests passing, reviewed, deployed to staging, documented

The distinction matters enormously in sprint reviews. A story that is "done" but not "done done" cannot be presented as a releasable increment — it still carries hidden risk. The phrase is a team shorthand for: "I'm not just saying I finished coding; I'm saying it's genuinely ready."

3 / 5

The team is updating their Definition of Done after a retrospective. They debate which entry is correctly written as a verifiable, observable DoD criterion.

Which of the following DoD entries is correctly written?

A well-written DoD entry must be observable — anyone can check it without subjective interpretation:

Option	Problem
A — "high quality and thoroughly tested"	Subjective: what counts as "high quality"? No measurable threshold.
B — "works correctly across all environments"	Vague: "works correctly" is subjective; "all environments" is undefined
C — "team members are satisfied"	Subjective and unmeasurable — satisfaction cannot be objectively verified
D — "80% branch coverage in CI report"	✓ Specific threshold, automated measurement, named evidence source

Each DoD entry should start with an action verb and specify an observable outcome: "Tests written and passing", "Code reviewed by at least one other developer", "Deployed to staging environment". If a criterion requires someone to make a judgement call, it will be interpreted inconsistently across team members.

4 / 5

During a retrospective, the team proposes adding "Deployed to production" as a criterion to their Definition of Done. The release manager says:

"I'd think carefully about that — it could create practical problems for how we close out stories during the sprint review."

Why might adding "Deployed to production" to the DoD create problems for this team?

Including "Deployed to production" in the DoD ties the team's ability to mark a story as done to external factors they may not control:

Scenario	Risk
Release requires sign-off from security / compliance	Story is blocked as "not done" even though engineering is complete
Coordinated release with other teams required	Sprint review cannot show "done" increment; velocity is distorted
Release window falls outside sprint boundary	Done stories carry over across sprints, breaking sprint goal clarity

Teams that practice continuous deployment and can safely deploy every merged PR may include this in their DoD without issue. For teams with managed or coordinated release processes, the better practice is "Deployed to staging, ready for production release" — keeping the DoD within the team's control.

5 / 5

After Sprint 22, a senior developer unilaterally adds three new items to the team's Definition of Done wiki page, saying: "I added these quality checks because I think we need them. I didn't want to wait until the next retro."

When should a Scrum Team update their Definition of Done, and what is wrong with this approach?

The Definition of Done is owned and maintained by the entire Scrum Team — not any individual member. Changes to it should follow a deliberate process:

Correct DoD change process	Why it matters
Raise the idea during a retrospective	All team members can discuss feasibility, impact, and trade-offs
Team agrees collectively on the new criterion	Shared ownership — no one is surprised by new quality requirements mid-sprint
New criterion takes effect from the next sprint	Prevents mid-sprint disruption; team has time to adjust workflow and capacity planning

A unilateral addition is problematic even when the intention is good: other team members may not know about it, it may affect sprint capacity (more time per story), and it erodes team trust in the shared quality agreement. The retrospective is the designated forum for this kind of improvement.