TECH **Definition of Done (DoD) vs. Acceptance Criteria: Zero-Fluff, Hands-On Agile Guide**

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

1. What This Is & Why It Matters

You’re a Scrum Team member (Developer, PO, or SM) working on a real-time payment processing system. The team just finished a sprint where they "completed" a new fraud detection feature. QA signs off, the Product Owner (PO) says "looks good," and the feature ships.

Two days later:
- Customers report false positives blocking legitimate transactions.
- The fraud model’s accuracy drops because the team forgot to retrain it on new data.
- The logging system fails silently, so no one notices the issue until complaints pile up.

Why did this happen?
The team confused Acceptance Criteria (AC) with the Definition of Done (DoD).
- AC = "Does this feature work as intended?" (e.g., "The fraud model must flag transactions over $10K with 95% accuracy").
- DoD = "Is this feature actually ready for production?" (e.g., "Model retrained, logs monitored, alerts configured, docs updated, security reviewed").

If you ignore DoD:
- Technical debt piles up (unmonitored systems, undocumented changes, security gaps).
- "Done" features break in production, eroding trust with stakeholders.
- Teams waste time fixing "completed" work instead of delivering new value.

If you master DoD:
- You ship reliable, maintainable features every sprint.
- Stakeholders trust your team’s estimates and commitments.
- You avoid the "90% done" trap (where the last 10% takes 90% of the effort).

Real-world scenario:
You’re inheriting a legacy microservice. The previous team marked stories as "Done" if they passed unit tests. Now, the service crashes in production because: - No load testing was done (DoD missing "performance tested").
- No alerts were set up (DoD missing "monitoring configured").
- No runbook exists (DoD missing "documentation updated").

This guide will show you exactly how to define and enforce DoD vs. AC so your team never ships half-baked features again.

2. Core Concepts & Components

3. Step-by-Step: How to Define DoD & AC for a Real Project

Prerequisites

• You’re part of a Scrum team (or pretending to be one for practice).
• You have a real or hypothetical project (e.g., a payment processing API, a SaaS dashboard, a mobile app).
• You have a backlog (even if it’s just 3-5 user stories).

Step 1: Draft Your Team’s DoD (15-30 min)

Goal: Create a universal checklist that applies to every work item in the sprint.

How to do it:
1. Gather the team (Developers, QA, DevOps, PO) for a 15-minute workshop.
2. Ask: "What’s the bare minimum we need to do to call something ‘Done’ and not regret it later?" 3. Start with these categories (add/remove as needed):
- Code Quality
- Testing
- Security
- Documentation
- Deployment
- Monitoring

Example DoD for a Web App Team:

### Definition of Done (DoD)
For all work items (stories, bugs, tasks):
✅ Code Quality
- [ ] Code reviewed by at least 1 other team member (GitHub PR approved).
- [ ] SonarQube scan passed (0 critical issues, coverage ≥ 80%).
- [ ] No hardcoded secrets (checked with `git-secrets` or TruffleHog).

✅ Testing
- [ ] Unit tests written and passing (Jest, pytest, etc.).
- [ ] Integration tests passing (Postman, Cypress, etc.).
- [ ] Manual QA sign-off (for UI changes).

✅ Security
- [ ] IAM roles follow least privilege (AWS, GCP, etc.).
- [ ] Dependencies updated (no CVEs with severity ≥ 7.0).
- [ ] Secrets stored in AWS Secrets Manager / HashiCorp Vault.

✅ Documentation
- [ ] README updated (if new feature).
- [ ] API docs updated (Swagger/OpenAPI).
- [ ] Runbook updated (for on-call).

✅ Deployment
- [ ] Changes deployed to staging (Terraform/Ansible).
- [ ] Feature flagged (if applicable).
- [ ] Rollback plan documented.

✅ Monitoring
- [ ] Logging configured (CloudWatch, ELK, etc.).
- [ ] Alerts set up (PagerDuty, Opsgenie).
- [ ] Dashboards updated (Grafana).

How to verify it works:
- Pick a recently "completed" story from your backlog.
- Check if it meets every DoD item.
- If not, add the missing items to DoD (e.g., "We forgot to update the runbook → add it to DoD").

Step 2: Write AC for a User Story (10-20 min)

Goal: Define story-specific conditions so the PO knows when to accept the work.

How to do it:
1. Pick a user story from your backlog (e.g., "As a user, I want to reset my password so I can regain access to my account").
2. Ask the PO: "What would make you say ‘Yes, this is done’?" 3. Write AC in Given-When-Then format (or bullet points if preferred).

Example AC for "Password Reset" Story:

### Acceptance Criteria
Scenario 1: Successful password reset
- Given a user has forgotten their password,
- When they enter their email on the reset page,
- Then they receive an email with a reset link within 5 seconds.

Scenario 2: Reset link expiration
- Given a user receives a reset link,
- When they click it after 1 hour,
- Then they see an error: "This link has expired."

Scenario 3: One-time use
- Given a user clicks a reset link,
- When they use it to set a new password,
- Then the link becomes invalid.

Scenario 4: Invalid email
- Given a user enters an email not in the system,
- When they submit the reset form,
- Then they see: "If this email exists, a reset link has been sent."

How to verify it works:
- Before development starts, review AC with the PO.
- After development, demo the feature and check off each AC item.
- If the PO says "This isn’t what I wanted", update the AC (not the DoD).

Step 3: Enforce DoD & AC in Your Workflow (Ongoing)

Goal: Make DoD and AC non-negotiable in your sprint.

How to do it:
1. Add DoD to your Definition of Ready (DoR):
- A story is not ready for sprint planning unless it has clear AC.
- A story is not "Done" unless it meets all DoD items.

1. Use GitHub/GitLab PR templates:
   ```markdown
   ## Definition of Done Checklist
2. [ ] Code reviewed by @teammate
3. [ ] SonarQube scan passed (0 critical issues)
4. [ ] Unit tests written and passing
5. [ ] Integration tests passing
6. [ ] Documentation updated

7. [ ] Monitoring configured
   ```

8. Automate DoD checks:

9. SonarQube for code quality.
10. TruffleHog for secrets scanning (trufflehog git https://github.com/your-repo).
11. Dependabot for dependency updates.

12. Terraform validate for infrastructure changes.

13. Sprint Review:

14. Demo the feature only if all DoD items are checked.
15. If a DoD item is missing, move the story back to "In Progress".

4. ? Production-Ready Best Practices

Security

• DoD: "All secrets must be stored in AWS Secrets Manager / HashiCorp Vault."
• Why? Hardcoded secrets in Git → data breaches (e.g., Uber’s 2022 breach).
• AC: "The API must reject requests with invalid JWT tokens within 100ms."
• Why? Slow auth checks → DDoS vulnerabilities.

Cost Optimization

• DoD: "All AWS resources must have cost tags (e.g., Environment=Staging)."
• Why? Untagged resources → surprise bills (e.g., forgotten EC2 instances).
• AC: "The Lambda function must complete within 500ms to stay in the free tier."
• Why? Long-running Lambdas → unexpected costs.

Reliability & Maintainability

• DoD: "All Terraform changes must be applied to staging before production."
• Why? Untested infra changes → outages (e.g., misconfigured security groups).
• AC: "The database migration must be reversible within 5 minutes."
• Why? Irreversible migrations → downtime (e.g., GitLab’s 2017 outage).

Observability

• DoD: "All new features must have CloudWatch alarms for errors and latency."
• Why? Unmonitored features → undetected failures (e.g., a payment API silently dropping transactions).
• AC: "The fraud detection model must log false positives to S3 for analysis."
• Why? No logs → can’t improve the model.

5. ⚠️ Common Mistakes & Traps

6. ? Exam/Certification Focus

Typical Question Patterns

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

3. Correct answer: "DoD is a universal quality checklist for all work items. AC is story-specific conditions for acceptance."

4. "Who is responsible for defining DoD?"

5. Trap answer: "The Product Owner." (PO owns AC, not DoD.)

6. Correct answer: "The entire Scrum Team (Developers, SM, PO) collaborates on DoD."

7. "When should AC be written?"

8. Trap answer: "During sprint planning." (Too late.)

9. Correct answer: "Before the story enters the sprint (part of Definition of Ready)."

10. "What happens if a story meets AC but not DoD?"

11. Trap answer: "The PO accepts it." (No!)
12. Correct answer: "The story is not Done and cannot be demoed in sprint review."

Scenario-Based Questions

Question:
"Your team’s DoD includes ‘Code reviewed by 2 team members.’ A story meets all AC but only 1 review. What do you do?"

Options:
A) Mark it as Done – the PO accepted it.
B) Move it back to "In Progress" – it doesn’t meet DoD.
C) Ask the SM to waive the DoD for this story.

Correct Answer: B
Why? DoD is non-negotiable. If you skip it, technical debt accumulates.

7. ? Hands-On Challenge

Challenge:
You’re a DevOps engineer on a team building a serverless URL shortener (AWS Lambda + DynamoDB). The PO just added this story:

"As a user, I want to shorten a URL so I can share it easily."

Your task:
1. Write Acceptance Criteria (AC) for this story.
2. Draft a Definition of Done (DoD) for the team (assume they’re new to serverless).

Solution:

Acceptance Criteria (AC)

### Acceptance Criteria
Scenario 1: Successful URL shortening
- Given a user enters a valid URL (e.g., `https://example.com`),
- When they click "Shorten,"
- Then they receive a shortened URL (e.g., `https://short.ly/abc123`).

Scenario 2: Invalid URL
- Given a user enters an invalid URL (e.g., `example`),
- When they click "Shorten,"
- Then they see an error: "Please enter a valid URL."

Scenario 3: Duplicate URL
- Given a user enters a URL that’s already been shortened,
- When they click "Shorten,"
- Then they receive the same shortened URL as before.

Scenario 4: Analytics
- Given a user shortens a URL,
- When they visit the analytics page,
- Then they see the number of clicks on their shortened URL.

Definition of Done (DoD)

### Definition of Done (DoD)
For all work items:
✅ Code Quality
- [ ] Code reviewed by 1 other team member.
- [ ] SonarQube scan passed (0 critical issues).
- [ ] No hardcoded secrets (checked with `git-secrets`).

✅ Testing
- [ ] Unit tests written and passing (Jest, pytest).
- [ ] Integration tests passing (Postman).
- [ ] Load test passed (1000 RPS with < 500ms latency).

✅ Security
- [ ] IAM roles follow least privilege (Lambda execution role).
- [ ] DynamoDB table encrypted at rest.
- [ ] API Gateway has rate limiting (1000 requests/minute).

✅ Documentation
- [ ] README updated (how to deploy, test, monitor).
- [ ] API docs updated (Swagger/OpenAPI).
- [ ] Runbook updated (how to handle Lambda timeouts).

✅ Deployment
- [ ] Changes deployed to staging (Terraform).
- [ ] Feature flagged (if applicable).
- [ ] Rollback plan documented.

✅ Monitoring
- [ ] CloudWatch alarms for errors and latency.
- [ ] X-Ray tracing enabled for Lambda.
- [ ] Dashboards updated (Grafana).

Why this works:
- AC ensures the feature works as intended (e.g., handles invalid URLs).
- DoD ensures the feature is production-ready (e.g., monitored, secure, documented).

8. ? Rapid-Reference Crib Sheet

9. ? Where to Go Next

1. Official Scrum Guide (DoD): [https://scrumguides.org/scrum-guide