Acceptance Criteria vs Definition of Done

Knowing the difference between acceptance criteria and definition of done is what separates a Scrum team that ships polished increments from one that argues during every sprint review. If you manage user stories in agile projects, this distinction decides whether your work gets accepted or sent back.

What are acceptance criteria in a user story?

Acceptance criteria are the specific conditions that confirm when a single user story is fully built and ready. They live attached to that story and only to that story, which means every item in your backlog carries its own set.

Think of them as the contract between the product owner and the developer for one piece of work. If the story says list verbs so the user learns meaning and pronunciation, the acceptance criteria spell out exactly what list means here.

Using the language learning app example, the criteria could look like this:

• The list must show the 100 most common irregular verbs.
• Each verb must include its present, simple past and past participle forms.
• The user must be able to sort the list alphabetically.
• The list must be visible on the app's main screen.

Notice how concrete each line is. There is no room for kind of done or almost there.

What are acceptance criteria? They are the unique conditions a single user story must meet to be considered complete. Each story has its own set, written before development starts.

How is the definition of done different from acceptance criteria?

The definition of done is a formal description of the increment when it meets the quality standards expected for the product. Unlike acceptance criteria, it applies to every user story the team delivers, not just one.

This is the quality gate. If a story does not meet the definition of done, it cannot be presented in the sprint review. Period. That rule is what protects your increment from shipping half baked work.

A solid first version of a definition of done usually includes:

• The code passes all automated quality tests.
• The code has been reviewed by another developer on the team.
• The functionality is deployed in a testing environment.
• The code is properly documented.

These are not negotiable per story. They are the baseline you apply across the board so the product stays consistent.

Can a story go to sprint review without meeting the definition of done? No. If the increment fails the definition of done, it is not eligible for sprint review, even if its acceptance criteria pass.

Why do both matter for sprint review and product quality?

Acceptance criteria reduce ambiguity about what you are building. The definition of done reduces uncertainty about how well you are building it. Together they cover both sides of the delivery equation.

When you skip acceptance criteria, developers guess at scope. When you skip the definition of done, quality drifts sprint after sprint until technical debt swallows your velocity. Holding both lines is what lets the team show real, working, trustworthy increments.

What happens if I only use acceptance criteria? You may deliver the right feature, but without a definition of done you cannot guarantee it meets quality standards like testing, code review or documentation.

How do I write my first definition of done?

Start small and make it enforceable. Pick three or four quality checks your team can actually verify every sprint, like automated tests passing, peer code review, deployment to a staging environment and basic documentation. You can expand the list as the team matures.

For acceptance criteria, write them with the product owner before the sprint starts, keep them specific and measurable, and review them during refinement so the whole team agrees on what done looks like for that story.

Now it is your turn. Take the user stories you defined in the previous class and write the acceptance criteria for each one. Then draft a first version of your definition of done, the one you will use to guarantee every story is ready for sprint review. Share your draft in the comments so we can compare approaches.