Criar Definition of Done para Equipes Dev | GitScrum
Crie DoD efetivo definindo critérios obrigatórios: código revisado, testes passando, docs atualizados. Documente no NoteVault para referência da equipe.
4 min de leitura
How to create Definition of Done for development teams?
Create Definition of Done (DoD) by defining criteria that every task must meet before moving to Done: code reviewed, tests passing, documentation updated, deployed to staging. Document in GitScrum NoteVault for team reference. Teams with clear DoD have 40% fewer defects and more predictable delivery [Source: Quality Engineering Research 2024].
Creating DoD steps:
Gather team - Collaborative definition List criteria - What means "done"? Prioritize - Essential vs nice-to-have Document - NoteVault record Communicate - Team alignment Enforce - Workflow integration Review - Regular updates
Essential DoD elements
| Category | Criteria |
|---|
| Code | Reviewed and approved |
| Tests | All passing |
| Quality | No critical bugs |
| Docs | Updated as needed |
| Deploy | To specified environment |
| Accept | Meets acceptance criteria |
DoD by task type
| Type | Additional Criteria |
|---|
| Feature | Demo-ready, stakeholder approved |
| Bug fix | Root cause documented |
| Refactor | No behavior change |
| Tech debt | Documented improvement |
| Hotfix | Rollback plan ready |
Sample DoD checklist
## Definition of Done
- [ ] Code reviewed and approved
- [ ] All tests passing (unit, integration)
- [ ] No new linter warnings
- [ ] Documentation updated
- [ ] Acceptance criteria verified
- [ ] Deployed to staging
- [ ] No known bugs
- [ ] Stakeholder approved (if applicable)
NoteVault DoD template
| Section | Content |
|---|
| Purpose | Why this DoD exists |
| Criteria | Checklist items |
| Exceptions | When to deviate |
| Owner | Who maintains |
| Last updated | Date |
Enforcing DoD
| Mechanism | Implementation |
|---|
| Checklist | Task description template |
| Column policy | Gate for Done column |
| PR template | DoD checklist |
| CI/CD | Automated checks |
| Code review | Reviewer validates |
| Retrospective | Compliance review |
DoD anti-patterns
| Anti-Pattern | Better Approach |
|---|
| Too long | Focus on essential |
| Ignored | Enforce via workflow |
| Never updated | Review quarterly |
| Different per person | Team-agreed standard |
| Only code quality | Include user value |
DoD evolution
| Stage | Focus |
|---|
| New team | Basic (tests, review) |
| Maturing | Add deployment, docs |
| Advanced | Include metrics, accessibility |
| Optimized | Continuous refinement |
Benefits of clear DoD
| Benefit | Impact |
|---|
| Fewer defects | Consistent quality |
| Predictability | Know when truly done |
| Less rework | Catch early |
| Team alignment | Shared understanding |
| Stakeholder trust | Reliable delivery |
DoD vs Acceptance Criteria
| DoD | Acceptance Criteria |
|---|
| Team-level standard | Task-specific |
| Universal for all tasks | Unique per user story |
| Quality focused | Functionality focused |
| Process criteria | Feature criteria |
Reviewing DoD effectiveness
| Metric | Indicates |
|---|
| Defect escape rate | DoD catching issues? |
| Rework percentage | Done really done? |
| Team satisfaction | DoD realistic? |
| Cycle time | DoD slowing flow? |
Related articles
