Visão geral
Definition of Done é uma técnica de entrega usada para eliminar ambiguidade sobre o que "pronto" significa para o time — evitando que design, dev e produto tenham expectativas diferentes sobre a completude de uma entrega, o que gera retrabalho e conflito. A utilidade dela está menos no ritual em si e mais na forma como ajuda o time a transformar uma dúvida de projeto em evidências, decisões ou próximos passos observáveis.
Ela faz sentido quando use ao formar novo time, ao iniciar novo projeto ou ao perceber que "pronto" está sendo interpretado diferentemente por áreas diferentes. Revise a cada ciclo conforme o produto e o time evoluem. Ao aplicar Definition of Done, o time deve chegar a lista acordada de critérios de done e Documento de referência publicado e acessível ao time, mantendo rastreabilidade entre o que foi observado, o que foi decidido e quais limites ainda precisam ser considerados.
Como entra no fluxo
Definition of Done entra quando já existe uma pergunta de trabalho clara e o time precisa conduzir uma atividade estruturada antes de avançar para decisão, protótipo, priorização ou entrega.
Atenção ao usar
DoD muito rígido pode bloquear entregas legítimas em contextos de urgência.
Combina bem com
Para que serve
Eliminar ambiguidade sobre o que "pronto" significa para o time — evitando que design, dev e produto tenham expectativas diferentes sobre a completude de uma entrega, o que gera retrabalho e conflito.
Quando usar
Use ao formar novo time, ao iniciar novo projeto ou ao perceber que "pronto" está sendo interpretado diferentemente por áreas diferentes. Revise a cada ciclo conforme o produto e o time evoluem.
Contexto
Objetivos
Outputs
Situações ideais
- equipe desalinhada
Como executar
Pré-requisitos
- Time representativo presente — produto, design e engenharia
- Exemplos de entregas recentes para calibrar o debate
Materiais
- Quadro ou ferramenta colaborativa
- Post-its ou equivalente digital
Passo a passo
- 1Pergunte ao time — o que precisa ser verdade para considerarmos algo pronto?
- 2Colete critérios individualmente antes de debater em grupo.
- 3Agrupe critérios por área — design, dev, teste, acessibilidade, documentação.
- 4Debata e valide cada critério — é realista? É verificável?
- 5Remova critérios aspiracionais que o time não consegue cumprir hoje.
- 6Publique e cole onde o time trabalha — é referência viva, não documento guardado.
- 7Revise a cada retrospectiva — o DoD deve evoluir com o time.
Critérios de qualidade
- Cada critério é verificável — binário, não sujeito a interpretação
- O DoD foi construído pelo time que vai usá-lo, não imposto
- Critérios cobrem qualidade de design, não só funcionalidade técnica
- O documento é acessível ao time no dia a dia — não só na wiki
Dicas
- Critério que ninguém verifica na prática deve ser removido ou ajustado.
- Inclua critérios de acessibilidade explicitamente — ficam de fora sem isso.
- Diferencie DoD do item (feature) do DoD do sprint — são granularidades diferentes.
- Conflitos sobre DoD revelam divergências de expectativa — são saudáveis de resolver.
Antes (entradas)
- Perspectivas de design, produto e engenharia sobre completude
- Exemplos de entregas recentes como calibração
Depois (saídas)
- Lista acordada de critérios de done
- Documento de referência publicado e acessível ao time
Variações
Definition of Ready
Versão que define critérios para uma história ou feature ser considerada pronta para entrar no sprint — problema definido, critérios de aceitação claros, design aprovado.
Uso estratégico
Quando evitar
- Time tem fluxo de entrega muito variável — DoD genérico não serve para todos os contextos
- Não há compromisso real de respeitar o DoD — vira burocracia sem consequência
Limitações
- DoD muito rígido pode bloquear entregas legítimas em contextos de urgência
- Precisa ser revisado regularmente ou fica desatualizado
Riscos
- DoD virar lista de verificação mecânica sem reflexão sobre qualidade real
- Critérios aspiracionais que nunca são cumpridos corroem a credibilidade do acordo
Exemplos de uso
- 01Definir critérios de done para time de produto que debate "está pronto" a cada sprint.
- 02Criar DoD específico para componentes de design system.
- 03Revisitar DoD após lançamento com bugs visuais repetidos.
Perfis responsáveis
Também conhecido como
Referências e leitura
Ajude a melhorar este conteúdo
Encontrou erro, lacuna técnica ou exemplo fraco? Envie uma correção com contexto para revisão.
