Definition of Done: Exemplo, checklist e workshop em Scrum

Outro dia, preparei um workshop junto com um colega. Chegamos rapidamente a um acordo sobre o conteúdo, a única coisa que faltava era uma apresentação em PowerPoint adequada. Para que você pudesse trabalhar na apresentação da forma mais eficiente possível, nós a dividimos por temas. Quando nos sentamos para discutir o rascunho finalizado, um grande problema ficou evidente: tínhamos ideias muito diferentes sobre o que realmente caracteriza um “rascunho finalizado”. 

Esse problema também pode surgir em equipes ágeis do Scrum. Depois de duas semanas, a equipe chega ao final do sprint, mas há discordância sobre se o incremento do produto já está concluído e pode ser movido de “em andamento” para “concluído”. Essa discordância leva a discussões que, por sua vez, influenciam negativamente o clima da equipe. Para evitar essas discussões e proteger o trabalho em equipe eficaz, existe um artefato no mundo do Scrum chamado “Definição de Pronto” (DoD). 

O que é a Definition of Done em Scrum?

A Definition of Done é o acordo comum de qualidade de uma equipe Scrum. Ela descreve quais პირობões precisam ser atendidas para que um incremento seja considerado concluído e utilizável. Não é uma lista pessoal de tarefas nem uma aprovação adicional feita por uma única função, mas um padrão transparente para toda a equipe.

Literalmente, Definition of Done significa “definição de concluído”. Isso significa que a equipe concorda com o que deve ser feito para que um recurso seja considerado concluído. Na prática, a Definition of Done pode ser representada como uma espécie de lista de verificação que é usada durante o sprint e, especialmente, no final para verificar se determinados critérios de conclusão foram atendidos. Para as equipes de desenvolvimento de software, esses critérios podem ser, por exemplo, os seguintes: 

Exemplo de Definition of Done: checklist para equipes Scrum

Uma Definition of Done prática pode conter, por exemplo, os seguintes critérios para um produto de software:

• Os critérios de aceitação e os requisitos funcionais estão atendidos.
• A documentação foi preparada.
• O código está totalmente implementado e comentado.
• Foi realizada uma revisão de código.
• Os testes automatizados são executados com sucesso; erros relevantes e riscos de segurança foram tratados.
• A alteração está integrada e pode ser verificada em um ambiente próximo ao de produção.
• Monitoring, logging e, quando aplicável, release notes foram considerados.
• O incremento é utilizável e atende ao padrão de qualidade do produto.
• …

Esta lista é um exemplo, não um modelo universal. Uma boa DoD protege a qualidade, permanece aplicável à equipe em cada Sprint e é ajustada quando o produto, os riscos ou as condições técnicas mudam.

Definition of Done não é a mesma coisa que impacto no produto

Uma Definition of Done responde a uma pergunta importante: o incremento atende ao padrão de qualidade acordado e é utilizável? Mas ela não responde automaticamente se a mudança alcança o efeito desejado no mercado ou junto ao cliente.

Para a prática, portanto, ajuda fazer uma distinção entre três níveis:

• Done: O incremento atende à Definition of Done e pode ser utilizado.
• Done-Done: A alteração está integrada, entregue e observável em operação.
• Impacto no produto: O feedback real dos clientes mostra se a alteração resolve um problema relevante e aumenta o valor do produto.

John Cutler descreve o software, por isso, como um sistema de serviços continuamente evoluído: recursos não são edifícios definitivos, mas meios temporários para gerar valor para o cliente. Leia sua perspectiva em The Work Is Never Done.

Além disso, Gil Zilberfeld distingue entre diferentes significados de “Done” – por exemplo, quando desenvolvimento, testes, entrega ou feedback do cliente marcam diferentes graus de conclusão. Você encontra sua classificação em The Definition of Done, Done-Done and Really Done.

Importante: “impacto no produto” não deve ser formulado simplesmente como um critério adicional de DoD. Uma equipe Scrum precisa entregar um incremento utilizável; se ele atinge o efeito desejado, isso se torna visível posteriormente por meio da Sprint Review, do uso e de outros ciclos de aprendizagem. სწორედ essa separação protege a Definition of Done de se tornar uma lista interminável e inalcançável.

Como a Definition of Done se articula com outras práticas eficazes de Scrum, mostramos em nosso artigo Scrum Best Practices 2026.

Por que uma Definição de Feito é importante?

O fato de a definição de metas ser de enorme importância para o desempenho não é uma percepção nova. A definição de metas é um tópico muito pesquisado em psicologia (cf. Locke e Latham, 2006). Foi demonstrado que o desempenho é mais alto quando as metas são tão específicas quanto possível e desafiadoras sem parecerem inatingíveis. A Definição de Feito não é, entretanto, um método de definição de metas (mas, se for usada, é um método de definição de metas). Apoio na definição de metas Se você precisar de ajuda, ficaremos felizes em ajudá-lo); é mais uma questão de critérios que precisam ser cumpridos para atingir a meta. 

Esses critérios são importantes para criar um entendimento comum na equipe. Uma compreensão do que cada membro da equipe deve alcançar para atingir o objetivo comum. Portanto, trata-se de desempenhos individuais que, em última análise, contribuem para o desempenho da equipe.

Se analisarmos a questão do DoD do ponto de vista do proprietário do produto, você verá problemas completamente diferentes. Se não estiver claramente definido quando um incremento de produto é considerado concluído, isso pode levar a desentendimentos com o cliente quando o produto for apresentado a ele. Se isso acontecer e um produto inacabado for apresentado, a possibilidade de feedback do cliente será bloqueada. 

Melhoria contínua

Como uma Definição de Pronto não é um conceito estático e pode e deve estar em constante evolução ou mudança, ela também oferece à equipe a oportunidade de aprender. Se, no final de um sprint, a equipe perceber que não conseguiu atender aos critérios da Definição de Pronto, os membros da equipe poderão ajustar a Definição de Pronto para acomodar o desempenho real ou a equipe tirará conclusões para o próximo sprint e mudará sua própria maneira de trabalhar.

Experimente o Echometer gratuitamente agora e obtenha nova inspiração para suas retrospectivas!

Teste o Echometer gratuitamente

Essas reflexões sobre a Definição de Feito devem ser feitas pela equipe durante a retrospectiva. Possível Itens EchometerAs perguntas que podem ser feitas durante a preparação são 

Temos definições claras de conclusão para nossos requisitos.

Normalmente, sei em que pé estamos para atingir nossos objetivos comuns.

Metas: Minhas metas estão alinhadas com as metas dos meus colegas.

A equipe abrange todas as habilidades necessárias para atingirmos nossa meta.

Eles não apenas questionam se há uma Definição de Trabalho na equipe, mas também como a transparência, a autonomia e a clareza de funções estão na equipe.

Você pode encontrar o conjunto completo de itens em nosso Ferramenta retrô.

Como nossa equipe pode definir o que foi feito? Um exemplo de workshop

Mostramos a você o que é uma Definição de Feito e por que ela é importante para uma colaboração eficaz nas equipes Scrum. Mas se a sua equipe ainda não criou uma DoD, você provavelmente está se perguntando como ela funciona. 

Em princípio, é importante que a equipe leve o tempo que for necessário para preparar o documento. No final, deve surgir um documento com o qual todos os membros da equipe possam se identificar e que não seja visto apenas como um mal necessário. Portanto, recomendamos um formato semelhante a um workshop com o Scrum Master como moderador. Cada membro da equipe deve pensar sobre quais critérios são importantes para a conclusão do produto e a equipe pode, então, resumir essas ideias. De forma análoga, desenvolvemos um formato de workshop para a definição de metas. Dê uma olhadapara você ter ideias para o workshop Definição de Feito! 

A DoD concluída pode ser usada em retrospectivas, por exemplo, na forma de um semáforo de Definição de Trabalho:  

1. Escreva seus critérios para a Definição de Feito abaixo de cada um deles.
2. Desenhe um quadrado vermelho, um amarelo e um verde ao lado de cada um deles.
3. Para cada item da Definição de Feito, cada membro da equipe marca se ele foi implementado bem, moderadamente bem ou mal no último sprint. 
4. Discuta os três com as menções mais frequentes na área vermelha.
5. Ajuste sua definição de Pronto, se necessário.

Conclusão - Concluído?

Algumas palavras para concluir: Não existe algo como “pronto” no ambiente ágil. Feito significa apenas que algo está provisoriamente concluído, mas ajustes e melhorias adicionais podem e devem ser feitos a qualquer momento. Esse é um dos muitos aspectos positivos do trabalho ágil: o aprimoramento contínuo. 

Particularmente empolgante: às vezes, os pontos são “concluídos” até que o cliente se apresente e questione toda a solução, abalando assim a base de suposições que você tem sobre as necessidades do cliente. Nessas situações, fica claro se a equipe realmente priorizou os benefícios para o cliente em detrimento do progresso no sistema de tíquetes.

Uma definição clara do que você fez pode evitar conflitos e aumentar seu desempenho. Se estiver interessado em mais maneiras de atingir esse objetivo, você também deve dar uma olhada em nosso artigo sobre a surpreendente verdade por trás da mentalidade ágil Veja. Ou enriqueça suas retrospectivas levando em conta as últimas descobertas científicas da psicologia.

Exatamente com essa promessa, desenvolvemos nossa ferramenta retro Echometer. Se você estiver interessado em saber como (e se) o Echometer funciona, leia o relato de experiência de Holger com nossa ferramenta:

Você quer levar sua equipe a um novo nível de desempenho? Nossa ferramenta Retro pode ajudar você a fazer isso. Aqui estão as experiências de Holger com ela:

Relatório de experiência de Holger sobre a ferramenta Remote Retro

Perguntas frequentes sobre a Definition of Done

O que deve constar em uma Definition of Done?

Em uma Definition of Done entram todos os critérios de qualidade que um incremento precisa atender para ser utilizável. Exemplos típicos são critérios de aceitação atendidos, code review, testes, verificação de segurança, documentação e a possibilidade técnica de entrega. Quais pontos se aplicam é decidido pela equipe para o seu contexto de produto.

Quem cria a Definition of Done no Scrum?

A equipe Scrum desenvolve e mantém a Definition of Done em conjunto. Ela não deve ser definida por uma única função como uma lista de controle. As organizações podem estabelecer padrões mínimos, mas a equipe precisa entendê-los e conseguir aplicá-los no dia a dia.

Qual é a diferença entre Definition of Done e Definition of Ready?

A Definition of Done descreve quando um incremento está concluído e utilizável. Uma Definition of Ready, por outro lado, pode conter critérios para a preparação de um item de trabalho, mas não é um artefato oficial do Scrum e não deve servir para deslocar responsabilidades ou ciclos de feedback.

Exemplo prático: Nossa Definition of Done interna na Echometer

Uma Definition of Done não precisa terminar em código e testes. Internamente, a Echometer utiliza um padrão mais abrangente, que, além da funcionalidade, também considera UX, manutenibilidade, observabilidade e a preparação do release. O exemplo a seguir mostra como uma equipe pode tornar seus próprios critérios de qualidade concretos e verificáveis:

Área	Critérios exemplares
Funcionalidade	A funcionalidade especificada funciona, os casos-limite típicos foram verificados, não há erros conhecidos, funções incompletas estão protegidas por feature flag e dados de uso relevantes são coletados.
UX	Estados vazios, estados de carregamento, permissões, tratamento de erros, localização e apresentação responsiva foram considerados.
Manutenibilidade	As Coding Guidelines e as convenções relevantes foram seguidas, código desnecessário e dívida técnica deixada de propósito foram evitados, e informações importantes para monitoramento e debugging estão disponíveis.
Deployment	A alteração foi disponibilizada em produção ou preparada deliberadamente por meio de feature flag, as release notes foram complementadas e as partes interessadas afetadas são informadas, se necessário.

Este exemplo, é claro, não é um modelo universal. Mas vocês podem usá-lo como base, enriquecê-lo com suas próprias definições, revisá-lo regularmente e desenvolvê-lo como um documento vivo.

Fontes

Locke, E. A., & Latham, G. P. (2006). New Directions in Goal-Setting Theory. Current Directions in Psychological Science, 15(5), 265–268. https://doi.org/10.1111/j.1467-8721.2006.00449.x