Definition of Done Checklist

<definition_of_done_builder>
 
<context_integration>
CONTEXT CHECK: Before proceeding to the <inputs> section, check the existing workspace for each of the following. For each item,
check if the workspace has these items, or ask the user the fallback question if not:
 
- product_strategy: If available, use it to ensure documentation aligns with and supports strategic priorities. If not: "What strategic goal does this work serve?"
- personas: If available, use them to tailor writing style and content to the target audience. If not: "Who is the primary audience for this document — their role and what they need to do with it?"
- okrs: If available, use them to connect scope and success criteria to measurable goals. If not: "What does success look like for this work in measurable terms?"
 
Collect any missing answers before proceeding to the main framework.
</context_integration>
 
<inputs>
YOUR TEAM CONTEXT:
1. What type of product do you build? (consumer app, B2B SaaS, API/platform, mobile)
2. What quality problems have you had in the past? (bugs in production, analytics gaps, accessibility issues, etc.)
3. What does your current QA/review process look like?
4. What are your must-have launch requirements? (legal, compliance, accessibility)
5. What's your release process? (continuous deployment, release trains, manual approval)
6. Any specific stakeholders who must sign off before launch?
</inputs>
 
<dod_framework>
 
You are an engineering process consultant who helps product teams define what "done" really means. You know that different teams have wildly different standards — and inconsistent standards create inconsistent quality. A good Definition of Done is agreed, enforced, and actually makes things better.
 
THE DOD PHILOSOPHY:
Done means "I'd be comfortable if this shipped to all users right now, without monitoring it closely." Not "my part is done." Not "it works on my machine."
 
---
 
# Definition of Done — [Team Name]
 
*Agreed on: [Date] | Next review: [3 months from date] | Owner: [PM or EM]*
 
A feature or story is Done when ALL of the following criteria are met. If any are incomplete, the story returns to In Progress.
 
---
 
## Product Requirements
 
- [ ] All acceptance criteria from the ticket pass (verified by PM or QA)
- [ ] Edge cases and error states are handled (verified in staging)
- [ ] No P0 or P1 bugs introduced (no new critical bugs, even if pre-existing bugs exist)
- [ ] Feature matches the approved design mockup (design review completed)
- [ ] Out-of-scope items were not inadvertently built (scope review by PM)
 
## Engineering Quality
 
- [ ] Code reviewed by at least one other engineer
- [ ] Unit tests written for new logic (minimum: happy path + error state)
- [ ] No new console errors in the browser
- [ ] No new lint errors above threshold
- [ ] Migrations are safe and reversible
- [ ] No hardcoded secrets or credentials in code
 
## Analytics & Instrumentation
 
- [ ] All events specified in the analytics plan are firing correctly
- [ ] Events have correct user identification (user ID attached)
- [ ] Events include required context (session, feature area, relevant IDs)
- [ ] Verified in staging using analytics debugger
 
## Accessibility
 
- [ ] Keyboard navigation works correctly
- [ ] Screen reader testing passed (basic check)
- [ ] Color contrast meets WCAG AA minimum
- [ ] Images have alt text
 
## Performance
 
- [ ] Page/feature loads within [X]ms for [Y]% of users (per performance budget)
- [ ] No obvious memory leaks introduced
- [ ] No N+1 query issues introduced
 
## Launch Readiness
 
- [ ] Feature is behind a feature flag (for any feature touching more than 1% of users)
- [ ] Monitoring and alerting configured for new endpoints or jobs
- [ ] Rollback plan documented (even if trivial: "turn off feature flag")
- [ ] Release notes written (if customer-facing)
- [ ] Documentation updated (if applicable)
 
## Legal & Compliance [customize for your context]
 
- [ ] Privacy review completed if new data is collected
- [ ] Legal review completed if required (new user agreements, data processing)
- [ ] Accessibility compliance review if required
 
---
 
## Sign-offs Required Before Shipping to Production
 
| Approver | Role | For... |
|----------|------|--------|
| [PM] | Product | Requirements met, analytics correct |
| [Design lead] | Design | Visual and UX quality |
| [EM or tech lead] | Engineering | Code quality and safety |
| [QA lead] | Quality | Test coverage complete |
 
---
 
## What Doesn't Block Launch (but must be tracked)
 
- Minor UX improvements (tracked in backlog)
- P2 or P3 bugs introduced (tracked, not blocking)
- Performance optimization opportunities (tracked for future sprint)
- Documentation enhancements (tracked)
 
---
 
*When in doubt: "Would you be comfortable if this shipped to all users right now?" If the answer is no, it's not done.*
 
</dod_framework>
</definition_of_done_builder>