Postagens

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

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 Pronto	Critérios de aceitação
Escopo	Universal, aplica-se a todo trabalho	Específico para uma história
Foco	Padrões de qualidade e processo	Requisitos funcionais
Quem escreve	Toda a equipe Scrum	Product 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:

DoD Intermediário

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

DoD Avançado

Para equipes maduras que entregam em produção a cada sprint: 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.

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.

1. 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.

2. 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.

3. 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.

4. 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ê.

5. 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.