Agile-and-Scrum: Definition of Done, DoD, vs. Acceptance Criteria - Zero-Fluff, Hands-On Scrum Guide

Definition of Done (DoD) vs Acceptance Criteria: Zero-Fluff, Hands-On Scrum Guide

(Scrum Guide 2020 Edition)

1. What This Is & Why It Matters

You’re a Scrum Team member (Developer, Scrum Master, or Product Owner) on a real-world project—maybe migrating a monolith to microservices, building a SaaS product, or shipping a critical security patch. Your sprint ends in 48 hours, and the Product Owner (PO) says: "Is this feature done? Can we ship it?"

If you answer "Yeah, the code works!" without checking Definition of Done (DoD) or Acceptance Criteria (AC), you’re setting yourself up for: - Production fires (e.g., missing logging, untested edge cases, security vulnerabilities). - Technical debt (e.g., undocumented APIs, no performance benchmarks). - Stakeholder rage (e.g., "Why does the mobile app crash on iOS 15?"). - Failed sprints (e.g., "We thought it was done, but QA found 20 bugs").

The Superpower

• DoD = The team’s shared quality standard (e.g., "All code must pass automated tests, be peer-reviewed, and deployed to staging").
• Acceptance Criteria = The specific conditions a single backlog item must meet to be "done" (e.g., "User can reset password via email; link expires in 1 hour").

Ignoring either = Chaos. Mastering both = Predictable, high-quality delivery.

2. Core Concepts & Components

? Definition of Done (DoD)

• What it is: A team-wide checklist of quality standards that every backlog item must meet to be considered "done."
• Production insight: If your DoD doesn’t include "Deployed to staging with monitoring enabled," you’ll ship bugs to production.
• Example (Cloud Dev Team DoD):
• Code reviewed (GitHub PR approved).
• Unit/integration tests pass (Jenkins pipeline green).
• Deployed to staging (Terraform apply).
• Performance benchmarked (e.g., <500ms response time).
• Security scan passed (Snyk/Trivy).
• Documentation updated (README, Swagger).
• PO demoed and accepted.

? Acceptance Criteria (AC)

• What it is: A per-item checklist of conditions that this specific backlog item must meet to be accepted by the PO.
• Production insight: If AC is vague ("User can log in"), you’ll waste time arguing over edge cases ("What if the password is wrong?").
• Example (User Story AC):
• User enters email/password-system validates format.
• Invalid credentials-error message: "Email or password incorrect."
• Correct credentials-redirect to dashboard.
• Session expires after 30 mins of inactivity.
• Password reset link sent within 60 seconds.

? DoD vs AC: Key Differences

? Why This Matters in Production

• Without DoD: Teams cut corners (e.g., skip security scans)-tech debt accumulates-production outages.
• Without AC: Developers build the wrong thing (e.g., "We thought ‘export’ meant CSV, but PO wanted PDF")-rework-missed deadlines.
• With Both:
• Predictable velocity (no surprises at sprint review).
• Higher quality (fewer bugs, better UX).
• Stakeholder trust (PO knows what "done" means).

3. Step-by-Step: Hands-On DoD & AC in Action

Prerequisites

• A Scrum Team (or a mock team if you’re solo).
• A backlog item (e.g., "As a user, I want to reset my password so I can regain access").
• A whiteboard or Confluence/Jira page.

Step 1: Define Your Team’s DoD (One-Time Setup)

1. Gather the team (Developers, PO, Scrum Master).
2. Ask: "What must be true for any backlog item to be ‘done’?"
3. Draft a checklist (example for a cloud team): ```markdown
4. [ ] Code reviewed (GitHub PR approved by 2 team members).
5. [ ] Unit tests pass (Jest/Cypress coverage-80%).
6. [ ] Integration tests pass (Postman/Newman).
7. [ ] Deployed to staging (Terraform + GitHub Actions).
8. [ ] Performance tested (Locust load test < 1s response time).
9. [ ] Security scan passed (Snyk/Trivy no critical vulnerabilities).
10. [ ] Documentation updated (README, Swagger, Confluence).
11. [ ] PO demoed and accepted. ```
12. Agree and document (e.g., in Confluence or team wiki).

Step 2: Write Acceptance Criteria for a Backlog Item

Backlog Item: "As a user, I want to reset my password so I can regain access."

1. PO + Developers refine the item (during backlog grooming).
2. Ask: "What must this feature do to be ‘accepted’?"
3. Draft AC (example): ```markdown
4. [ ] User enters email-system validates format (e.g., [email protected]).
5. [ ] Invalid email-error: "Email not found."
6. [ ] Valid email-system sends reset link to email within 60s.
7. [ ] Reset link expires after 1 hour.
8. [ ] User clicks link-redirected to password reset page.
9. [ ] New password must be-8 chars, with 1 number/symbol.
10. [ ] Password reset-user logged in automatically.
11. [ ] Failed attempts (3+)-lock account for 15 mins. ```
12. Review with PO (e.g., "Should the link expire in 30 mins instead?").

Step 3: Implement & Verify Against DoD + AC

Task: Build the password reset feature.

1. Developer codes the feature (e.g., React frontend + Node.js backend).
2. Before marking "done," check:
3. DoD:
   • ? Code reviewed? (GitHub PR approved).
   • ? Tests pass? (Jest coverage-80%).
   • ? Deployed to staging? (kubectl apply -f k8s/manifests).
   • ? Security scan passed? (trivy fs .).
4. AC:
   • ? User can enter email? (Tested manually).
   • ? Reset link expires in 1 hour? (Check DB expires_at field).
   • ? Password rules enforced? (Test with "password" vs "P@ssw0rd").
5. Demo to PO (e.g., "Here’s the reset flow—link expires in 1 hour, as agreed").
6. PO accepts-item is "done."

Step 4: Automate DoD Checks (Optional but Recommended)

Example: GitHub Actions workflow to enforce DoD:

name: DoD Check
on: [pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm test  # Unit tests
      - run: npx cypress run  # Integration tests
      - run: trivy fs .  # Security scan
      - run: npm run build  # Build check

Why? Ensures no one merges code that violates DoD.

4.-Production-Ready Best Practices

Security

• DoD: Include "Security scan passed (no critical vulnerabilities)."
• AC: For sensitive features (e.g., payments), add "PCI DSS compliance verified."

Cost Optimization

• DoD: "Infrastructure cost estimated (e.g., AWS Cost Explorer report)."
• AC: For cloud features, add "Uses spot instances for non-critical workloads."

Reliability & Maintainability

• DoD: "Monitoring enabled (Prometheus alerts for 5xx errors)."
• AC: For APIs, add "Swagger docs updated with example requests/responses."

Observability

• DoD: "Logging implemented (ELK stack or CloudWatch)."
• AC: For user flows, add "Analytics event fired on password reset."

5. Common Mistakes & Traps

6.-Exam/Certification Focus (PSM, CSM, etc.)

Typical Question Patterns

1. "What’s the difference between DoD and AC?"
2. Trap: "DoD is for the team, AC is for the PO." (Too vague.)

3. Correct: "DoD is a team-wide quality standard for all items; AC is per-item conditions for acceptance."

4. "Who defines the DoD?"

5. Trap: "The Product Owner." (Wrong—PO owns the backlog, not quality standards.)

6. Correct: "The entire Scrum Team (Developers, PO, Scrum Master)."

7. "When should AC be written?"

8. Trap: "During sprint planning." (Too late—refinement happens earlier.)
9. Correct: "During backlog refinement (before sprint planning)."

Scenario-Based Questions

Q: "Your team’s DoD says ‘All code must be peer-reviewed,’ but a critical bug fix needs to ship ASAP. What do you do?" - Trap: "Skip the review—ship it!" (Violates DoD-tech debt.) - Correct: "Follow the DoD (review first), but expedite the process (e.g., pair programming + fast-track review)."

Q: "A backlog item’s AC says ‘User can export data as CSV,’ but the PO now wants PDF. What do you do?" - Trap: "Build PDF—it’s just a small change." (Scope creep-missed deadlines.) - Correct: "Update the AC in backlog refinement, re-estimate, and prioritize in the next sprint."

7.-Hands-On Challenge

Challenge: You’re a Scrum Team building a "User Profile" feature. The PO says: "Users should be able to update their name, email, and profile picture."

Task:
1. Write Acceptance Criteria for this item (use Given-When-Then format).
2. Draft a DoD for your team (assume you’re a cloud team using AWS).

Solution: Acceptance Criteria:

- [ ] Given a logged-in user, when they navigate to "/profile," then they see their current name, email, and profile picture.
- [ ] Given a user edits their name, when they click "Save," then the new name is displayed immediately.
- [ ] Given a user uploads a profile picture (PNG/JPG-5MB), when they click "Save," then the image is resized to 200x200px and stored in S3.
- [ ] Given a user enters an invalid email (e.g., "user@"), when they click "Save," then an error appears: *"Please enter a valid email."*
- [ ] Given a user updates their email, when they click "Save," then a verification email is sent to the new address.

DoD (Cloud Team Example):

- [ ] Code reviewed (GitHub PR approved by 2 team members).
- [ ] Unit tests pass (Jest coverage-80%).
- [ ] Integration tests pass (Postman/Newman).
- [ ] Deployed to staging (Terraform + GitHub Actions).
- [ ] S3 bucket configured with lifecycle policy (delete old profile pics after 30 days).
- [ ] CloudFront CDN cache invalidated for profile pictures.
- [ ] Security scan passed (Snyk/Trivy no critical vulnerabilities).
- [ ] PO demoed and accepted.

Why It Works: - AC covers edge cases (invalid email, image resizing). - DoD ensures quality (tests, security, cost optimization).

8.-Rapid-Reference Crib Sheet

9.-Where to Go Next

1. Scrum Guide 2020 (Official): https://scrumguides.org/scrum-guide.html (Search for "Definition of Done").
2. Agile Alliance – DoD vs AC: https://www.agilealliance.org/glossary/definition-of-done/
3. Atlassian – Writing Good AC: https://www.atlassian.com/agile/project-management/user-stories
4. Book: "Scrum: The Art of Doing Twice the Work in Half the Time" (Jeff Sutherland) – Chapter 5 (DoD).

Final Pro Tip:

"If your DoD is a wall of text, it’s useless. If your AC is ‘It works,’ you’re doomed. Keep both short, specific, and automated—or pay the price in production."

Now go update your team’s DoD and AC before your next sprint! ?