TL;DR:
Definition of Done (DoD)
= the team’s quality checklist for any product backlog item.
Acceptance Criteria = the specific expectations for one user story to be accepted as “done.”
Basically, one is team-wide, the other is story-specific. Know the difference, save a sprint.
So, what the heck is the Definition of Done (DoD)?
Imagine you’re baking cookies (stay with me).
The Definition of Done is your master cookie checklist. Not burnt? Check. Chocolate chips actually inside the dough, not just floating around the tray? Check. Cooled down and not likely to melt your teeth? Check.
DoD is the universal agreement in your team that says: No matter what we’re building — this is what “done” means. It’s the quality bar. It’s the unspoken (but actually written down) rulebook.
Examples of DoD elements:
- Code is written, reviewed, and merged (no rogue cowboys pushing to main)
- Unit tests are at 80% coverage (no, 30% is not “close enough”)
- Deployed to staging
- Documentation updated (yes, even the one Bob always forgets)
Definition of Done: How to Not Suck at It
Let’s call these the DoD success principles. They’re like commandments but with less lightning and more Jira:
- Shared Understanding — Everyone agrees. No one says, “Wait, we do that now?”
- Applies Everywhere — It’s for every backlog item. If it doesn’t apply, question your DoD, not the laws of physics.
- Quality & Consistency — It’s not just about delivery. It’s about delivering stuff you’re not ashamed of demoing.
- Realistic — Don’t go full fantasy mode. If your team of two says DoD includes “full regression testing on five browsers,” you’re setting yourselves up for sprint-induced tears.
Good DoD example:
✔ Code is peer-reviewed
✔ Security checks passed
✔ Deployed to staging
✔ PO has signed off
Bad DoD example:
✘ “Works on my machine”
✘ “If it compiles, it ships”
✘ “Tested” (by whom? Your dog?)
Now, let’s talk Acceptance Criteria (AC)
If DoD is your master cookie checklist, Acceptance Criteria is the recipe for a specific cookie. Oatmeal with raisins? Ew, but okay. Your AC says: must be chewy, contain raisins, and taste better than cardboard.
Acceptance Criteria are the rules a single user story must meet to be accepted by the Product Owner. They’re the story’s personal checklist.
Example user story:
As a user, I want to reset my password so I can access my account after I forget what ridiculous combination I used.
Acceptance Criteria for this story:
- User receives an email with a reset link
- The reset link expires after 30 minutes
- User is prompted to create a new password (minimum 8 characters, 1 special character, no emoji passwords yet)
- User sees a confirmation message after reset
Acceptance Criteria: How to Nail It
- Clear & Specific — No fuzzy phrases like “should be user-friendly” (what does that even mean?)
- Testable — If you can’t test it, you can’t accept it. “Feels smooth” isn’t a valid pass/fail.
- Relevant — Tailored to the story, not generic fluff. Don’t copy-paste AC from another story because you’re late for lunch.
- Collaborative — Created with input from the PO, developers, and testers. Not in a vacuum (unless you’re building something for a vacuum).
Good AC example:
✔ Must log failed attempts and lock user out after 5 tries
✔ Redirects to login page after successful reset
Bad AC example:
✘ “Should be nice”
✘ “Button should work” (work how? explode? teleport the user?)
DoD vs Acceptance Criteria: The Final Showdown
Let’s break this down like a therapy session for confused product teams:
In simpler terms:
If DoD is the universal rule that says “this house is clean,”
Acceptance Criteria are the checklist that says “this room has been vacuumed, mopped, and doesn’t smell like disappointment.”
Real-Life Analogy Time (Because Life Is Scrum-ish)
Let’s say you’re moving into a new apartment.
Definition of Done for Moving In:
- All boxes unpacked
- Internet working
- No mysterious smells
- Utilities transferred
- All IKEA furniture assembled without a single leftover screw (ha, good luck)
Acceptance Criteria for “Set up living room”:
- TV mounted
- Couch assembled
- PS5 connected and tested (priorities!)
- Lamp works via smart plug
- No cables resembling spaghetti monster attacks
See the difference? One ensures the whole move is complete and quality-approved, the other makes sure that one room is good to go.
Wrap-Up (a.k.a., What You Should Tattoo on Your Scrum Board)
- DoD is the team’s baseline quality agreement.
- Acceptance Criteria are the pass/fail conditions for individual stories.
- They work together — one doesn’t replace the other.
- If you confuse them, your PO, QA, and Sprint Review will confuse you right back. Hard.
Pro tip:
When in doubt, ask: “Is this a general standard or specific to this story?” Boom — clarity.
Want more techie wisdom wrapped in sass and sarcasm? Stick around. Because we’re just getting started.
🔥If you liked this article, check out the next one where we share what Product Owners, Product Managers, Project Managers, and Delivery Managers actually do—finally, a clear breakdown of tech roles.
Written by
Simina F.
| howtobecomeapm.com – Author
|
Leave a Reply