Definition of Done vs Acceptance Criteria: Key Differences

Honestly, this one trips up experienced teams too. I've sat in sprint reviews where the developer says "it's done" and the product owner says "it really isn't," and both of them were telling the truth. They just meant different things by done. That's the whole problem with the definition of done and acceptance criteria. Both are checklists, both live near the end of a story, and people use the words as if they were the same thing. (They aren't.)

Over the next few minutes we'll cover what each one is, push a single story through both, and then get to the mistakes that cause the most grief. And if your stories are a bit fuzzy to begin with, read how to write user stories before you come back.

What is the definition of done?

Think of it as the team's standing promise about quality. Nothing counts as finished until it clears the same bar. Fifteen minute fix, three week feature, same bar. The Scrum Guide has a proper formal wording for it, but on most teams it ends up as a short list stuck to the top of the board, and honestly that's where it works best.

What goes on the list

Lists vary, and yours should too. A fairly typical one for a software team:

• A second pair of eyes on the code

• Tests written, and they pass

• No new serious bugs open

• Running on staging

• Docs and release notes updated

• Product owner has seen it work

Spot what's missing? Nothing about what the feature does. That's on purpose. The list couldn't care less whether it's a login fix or a reporting screen. It just wants to know the thing was built properly.

What are acceptance criteria?

Acceptance criteria are the other half, and they're personal to each story. The question they answer is simple. If I showed this to the product owner right now, would they say yes? Some teams write them as Given, When, Then. Some just write sentences. I don't mind which, as long as people actually read them.

An example you can steal

Take the story "As a project manager, I want to filter tasks by assignee so I can spot who's overloaded." The criteria might be:

• Pick one person and only their tasks show up

• Clear the filter and everything comes back

• Filter by someone with no tasks and you see a friendly message, not a blank screen

• Refresh the page and the filter is still there

Try pasting those onto a different story and they fall apart. They only make sense here, which is exactly what separates a criterion from a general rule.

Definition of done vs acceptance criteria at a glance

Not sure where a line belongs? Ask yourself if it would apply to every story. If yes, it's DoD. If no, it's a criterion.

One story, two ways to get it wrong

Meeting the criteria but not the DoD

Take the story "Export a sprint report as a PDF." The criteria say it must include the sprint goal, the burndown chart and the list of finished stories, and download in under ten seconds for a sprint of 50 stories. The developer nails it. Honestly, the PDF looks great, so the card slides into Done. Then someone asks who reviewed the code. Silence. Tests? Not yet. Release notes? Oh, right. The story works, sure, but it isn't finished, and next month's bug lands on whoever touches that code.

Meeting the DoD but not the criteria

Now the reverse. Reviewed, tested, deployed to staging, everything ticked. But nobody went back to the criteria, and the burndown chart never made it into the PDF. You've got something clean and well tested that doesn't do what was asked. I'd say this one stings more, because everyone feels finished and the review feels like an ambush.

The fix is boring, and that's the good news. Write the criteria before work starts, keep the DoD visible, done. Teams that do both barely argue in reviews, since the argument already happened in refinement, when it costs almost nothing.

Who owns which one

Acceptance criteria

The product owner usually starts them, because they know what the customer wants. Developers should push back during refinement. If nobody can say how to test a line, rewrite the line.

The definition of done

This one's the team's. Got a company wide standard? Treat it as the minimum. Add whatever you like on top, but don't quietly delete lines from it.

How to build a definition of done people will follow

Skip the half day workshop. A rough draft written over coffee beats a perfect one nobody finishes.

• Start with five to eight lines

• Make each one a clear yes or no

• Keep it where people see it every day

• Revisit it every few sprints and cut whatever everyone ignores

That last one matters more than it sounds. A DoD the team ignores is worse than no DoD at all. It teaches everybody that the rules are decoration.

Mistakes that come up again and again

Pasting the DoD into every story

Same line on ten stories? Move it to the DoD. Your stories get shorter and nobody misses the clutter.

Writing criteria once work is underway

By then you're just describing what got built instead of what was wanted. Write them first, even if they're rough.

Using vague words

Fast. Simple. User friendly. Nobody can test those. "Loads in under two seconds" you can test, so write that.

Letting the list balloon

Hit twenty five items and people stop reading by week three. Trim it, then trim it again.

Moving the goalposts mid sprint

Need to raise the bar? Say so in the retro, agree, and start next sprint. Changing it quietly just breeds resentment.

Using both when you plan the sprint

Before a story goes in, I'd ask three things:

• Are the acceptance criteria written down?

• Can someone explain how each line gets checked?

• Did the estimate include the DoD work?

Any no, and the story waits. Twenty lost minutes in planning is cheaper than a lost day at the end of the sprint. Also, the DoD isn't free. Reviews, tests and docs take real time, which is why estimates that ignore them always run low. Our sprint planning best practices cover how to run that conversation, and if anyone on the team is new to the language, the agile glossary pt.3 (iteration, velocity, user story) helps.

One small habit I like. At the start of a review, read the criteria out loud before anybody demos a thing. Feels a bit silly. Keeps the demo honest though.

Where Sanplex fits

With Sanplex you set your own workflow statuses, so your definition of done can sit right inside the workflow. A story can't move to Done until it has gone through the review and testing steps you set up. Acceptance criteria stay inside the story itself, so people see them from refinement all the way to review.

Frequently asked questions

What is the difference between definition of done and acceptance criteria?

The definition of done is one quality checklist for everything the team delivers. Acceptance criteria belong to a single story. Work is only finished when it passes both, not one or the other.

Can a story go into a sprint without acceptance criteria?

It can, but I wouldn't risk it. The team and the product owner will probably picture two different results, and you only find out at review. Even two or three plain lines make a difference.

Who writes the definition of done?

The team, together, ideally in one short session. If your company already has a standard, start from that and add what your team needs.

How often should we change our definition of done?

Not often. When the team agrees the bar should move, usually in a retro, change it and apply it from the next sprint so nobody gets surprised.

Are acceptance criteria the same as test cases?

Not quite. Criteria say what the feature should do, in plain words. Test cases are the step by step checks that prove it. Good criteria make writing test cases a lot easier.