logo
Retrospectivas
Poker de Planejamento
Standups
Quebra-gelos
Preços
Painel de Controle

Postagens

O checklist de definição de pronto que sua equipe realmente precisa

Equipe ágil reunida em torno de um quadro branco com um checklist concluído, comemorando após finalizar um incremento do sprint
Matt Lewandowski

Matt Lewandowski

Última atualização 14/02/20268 min de leitura

Toda equipe Scrum tem aquele momento em que alguém marca uma história como "pronta" e outra pessoa pergunta: "mas você escreveu os testes?" Essa lacuna entre o que uma pessoa considera finalizado e o que a equipe realmente precisa é exatamente o que a Definição de Pronto resolve. O Guia Scrum de 2020 elevou o DoD de algo opcional para um compromisso formal vinculado ao Incremento. No entanto, a pesquisa do Ron Lichty sobre Performance de Equipes de Produto mostra que apenas 45% das equipes possuem um DoD criado pela própria equipe. O restante trabalha sem um ou segue um checklist que outra pessoa criou para eles. A parte interessante: apenas definições de pronto criadas pela equipe se correlacionam com alta performance. As impostas externamente não mostram correlação alguma.

O que a definição de pronto realmente é

O DoD é um padrão de qualidade compartilhado que se aplica a cada entrega da sua equipe. Não é a mesma coisa que critérios de aceitação.
Definição de ProntoCritérios de aceitação
EscopoUniversal, aplica-se a todo trabalhoEspecífico para uma história
FocoPadrões de qualidade e processoRequisitos funcionais
Quem escreveToda a equipe ScrumProduct Owner (com contribuição da equipe)
Exemplo"Código revisado por pelo menos um dev""Usuário pode filtrar por intervalo de datas"
Ambos precisam ser satisfeitos antes que uma história seja concluída. Os critérios de aceitação dizem o que construir. O DoD diz quão bem precisa ser construído.

Um checklist de definição de pronto em três níveis

Nem toda equipe precisa do mesmo DoD. Uma startup lançando seu MVP tem necessidades de qualidade diferentes de uma plataforma de saúde com requisitos de conformidade. Aqui está uma abordagem em camadas.

DoD Inicial

Para equipes que estão começando com uma definição de pronto formal:

Código revisado por pelo menos um outro desenvolvedor

Testes unitários escritos e passando

Sem novos avisos ou erros do compilador

Critérios de aceitação verificados

Código mesclado na branch principal

Build realizado com sucesso a partir do controle de versão

DoD Intermediário

Para equipes com CI/CD estabelecido e alguns sprints de experiência:

Código revisado por pelo menos um outro desenvolvedor

Testes unitários escritos e passando

Cobertura de código não diminui abaixo do limite atual

Testes de integração passando

Sem bugs críticos ou de alta severidade remanescentes

Critérios de aceitação verificados de ponta a ponta

Implantado no ambiente de staging

Product Owner revisou e aprovou

Documentação técnica atualizada

Padrões de acessibilidade atendidos

DoD Avançado

Para equipes maduras que entregam em produção a cada sprint:

Código revisado por pelo menos um outro desenvolvedor

Testes unitários, de integração e de regressão passando

Cobertura de código mantida ou melhorada

Verificação de vulnerabilidades de segurança aprovada

Benchmarks de performance atingidos

Implantado em produção com feature flag

Monitoramento e alertas configurados

Documentação voltada ao usuário atualizada

Notas de versão escritas

Critérios de aceitação verificados em produção

Aprovação do Product Owner concluída

Equipe observando um monitor grande exibindo um pipeline de CI/CD com marcações verdes em cada etapa, representando portões de qualidade automatizados O nível certo depende do seu contexto. Comece com um checklist que sua equipe consiga cumprir de forma consistente e depois aumente o padrão ao longo do tempo. Adicionar itens que sua equipe rotineiramente ignora apenas treina todos a ignorar o DoD por completo.

Por que o DoD importa mais do que você imagina para estimativas

É aqui que a maioria dos artigos sobre definição de pronto para. Mas a ligação entre DoD e precisão nas estimativas é a razão mais subestimada para acertá-lo. O Guia Scrum diz claramente: os desenvolvedores fazem previsões com mais confiança quando entendem sua Definição de Pronto. Quando sua equipe estima uma história durante o planning poker, essa estimativa deve incluir tudo o que é necessário para atender o DoD. Não apenas escrever o código, mas a revisão, os testes, a implantação, tudo. Equipes que estimam apenas o esforço de codificação e depois descobrem as atividades do DoD no final do sprint consistentemente se comprometem demais. O trabalho não demorou mais do que o estimado. A estimativa é que ignorou metade do trabalho. Quando você adiciona novos itens ao seu DoD (como verificação de segurança ou testes de performance), espere que a velocidade caia temporariamente. Isso é saudável. Sua velocidade está apenas se tornando honesta.

Cinco anti-padrões que comprometem seu DoD

1. Definir e esquecer

A equipe escreveu um DoD há seis meses e não olhou para ele desde então. Ferramentas mudam e o produto cresce. Revise o DoD nas suas retrospectivas mesmo que você não o altere todas as vezes.

2. Criado por uma única pessoa

Um tech lead ou Scrum Master elabora o DoD sozinho e o apresenta como final. O resto da equipe nunca sente propriedade sobre ele, então o trata como opcional. A solução: construam juntos em um workshop. Todos que fazem o trabalho devem ter voz no que "pronto" significa.

3. Vago demais para verificar

"Código de boa qualidade" e "testes feitos" não são verificáveis. Cada item deve ter uma condição clara de aprovação/reprovação. "Código passa na análise estática com zero problemas críticos" é algo que você pode verificar. "Código está limpo" é questão de opinião. Pessoa olhando para um checklist gigante com alguns itens claramente marcados como prontos e outros ambíguos, ilustrando a diferença entre critérios vagos e específicos

4. Baixar o padrão sob pressão

Quando os prazos apertam, as equipes às vezes enfraquecem o DoD para entregar mais rápido. O Guia Scrum de 2020 é explícito aqui: o DoD pode evoluir para melhorar a qualidade, mas não deve ser enfraquecido. Cortar atalhos na qualidade não acelera você. Cria a ilusão de velocidade enquanto acumula problemas para sprints futuros.

5. Confundir DoD com critérios de aceitação

O DoD é universal. Critérios de aceitação são específicos de cada história. Misturá-los significa que você perde o padrão de qualidade ou esquece os requisitos funcionais. Mantenha-os como checklists separados que funcionam juntos.

Como construir seu primeiro DoD

Se sua equipe ainda não tem uma definição de pronto, aqui está uma forma prática de criar uma. Para um ponto de partida rápido, um gerador de definition of done pode elaborar uma checklist inicial baseada no contexto da sua equipe.
Comece com o que já está acontecendo
Pergunte à sua equipe: "O que já fazemos antes de considerar algo pronto?" Anote cada resposta. A maioria das equipes já possui padrões informais que não foram documentados.
Identifique as lacunas
Analise bugs recentes ou incidentes em produção. O que teria detectado esses problemas mais cedo? Essas lacunas se tornam candidatas a novos itens do DoD.
Mantenha curto
Mire em 6 a 12 itens. Cada item deve justificar sua presença prevenindo uma categoria real de problema. Se você não consegue apontar um problema específico que um item detectaria, remova-o.
Torne visível
Coloque o DoD onde a equipe possa vê-lo durante o planejamento do sprint e o trabalho diário. Um checklist enterrado em uma wiki é um checklist que ninguém lê.
Revise a cada retrospectiva
Adicione um item fixo na agenda das suas retrospectivas. Pergunte: "O DoD detectou o que precisava? Algo passou despercebido? Devemos adicionar ou remover itens?"

O que equipes de alta performance fazem de diferente

A pesquisa de Ron Lichty aponta um padrão claro. Equipes de alta performance são donas do seu DoD e o evoluem deliberadamente. Elas também o usam para manter as estimativas honestas em vez de otimistas. Essas equipes automatizam o máximo possível do checklist. Verificações de cobertura de código e análise estática são executadas em pipelines de CI/CD junto com verificações de segurança. O DoD é aplicado pelo sistema em vez de depender da memória, o que libera a equipe para focar nos itens que realmente exigem julgamento humano, como se os critérios de aceitação foram atendidos da perspectiva do usuário. As equipes mais maduras vinculam seu DoD a resultados de negócio, não apenas a padrões técnicos. Martin Hinshelwood dá um exemplo: "Em produção, coletando telemetria, apoiando ou refutando a hipótese inicial." Essa é uma equipe cuja definição de pronto não é apenas "o código funciona", mas "estamos aprendendo com o que entregamos."

Primeiros passos

Escolha três itens do checklist inicial acima. Escreva-os em um quadro branco ou coloque-os em um documento compartilhado. Use-os por um sprint. Na retrospectiva, pergunte o que funcionou e o que está faltando. Adicione um ou dois itens. Repita. Um DoD pequeno e consistente que a equipe realmente segue supera um abrangente que todos ignoram. Construa o hábito primeiro, depois aumente o padrão. E da próxima vez que alguém perguntar se uma história está pronta, você terá uma resposta que não exige uma conversa de 10 minutos. Se sua equipe usa planning poker para estimativas, mantenha o DoD visível durante essas sessões. É a forma mais rápida de garantir que as estimativas reflitam o escopo completo do que "pronto" realmente significa.

Revise a cada retrospectiva de sprint. Na maioria dos sprints você não mudará nada, mas o hábito mantém o DoD relevante. Atualize-o quando encontrar lacunas recorrentes de qualidade ou quando novas ferramentas tornarem itens existentes automatizáveis.

O Guia Scrum diz que se uma organização possui um DoD padrão, as equipes devem segui-lo como mínimo. As equipes podem adicionar padrões mais rigorosos por cima. Na prática, cada equipe deve ser dona dos itens além da linha base organizacional.

A Definição de Preparado aborda se um item do backlog tem informação suficiente para iniciar o trabalho (requisitos claros, dependências identificadas). A Definição de Pronto aborda se o trabalho finalizado atende aos padrões de qualidade. Preparado é o portão de entrada, Pronto é o portão de saída.

Não. Se não atende ao DoD completo, não está pronta. Ela volta para o backlog do produto. Trabalho parcialmente finalizado nunca deve ser apresentado na revisão do sprint ou contado na velocidade.