No framework Scrum, um dos pilares fundamentais para a entrega de produtos de qualidade é a transparência. Para que todos os envolvidos em um projeto compartilhem uma compreensão clara do que foi concluído, o Definition of Done (D.o.D.) se apresenta como uma ferramenta essencial.

O D.o.D. é mais do que um simples checklist: é uma descrição formal que define quando um incremento atinge as medidas de qualidade necessárias para ser considerado finalizado. Sem essa definição, o progresso e a entrega do produto podem ser comprometidos, com trabalho incompleto sendo liberado ou mal interpretado.

Neste artigo, exploraremos o que é o Definition of Done, como ele funciona segundo oScrum Guide, e sua importância na prática, tanto para equipes individuais quanto para múltiplos times Scrum trabalhando em um único produto.

O que é o Definition of Done?

O Definition of Done (D.o.D.), conforme descrito no Scrum Guide, é uma descrição formal do estado de um incremento quando ele atende às medidas de qualidade exigidas para o produto.

No momento em que um item do Product Backlog atende ao Definition of Done, um incremento é considerado concluído. O D.o.D. promove transparência ao proporcionar a todos os envolvidos um entendimento compartilhado sobre o que foi efetivamente completado como parte do incremento.

Se um item do Product Backlog não atende ao D.o.D., ele:

• Não pode ser liberado.
• Não deve ser apresentado na Sprint Review.
• Deve retornar ao Product Backlog para consideração futura.

Quando o Definition of Done é parte dos padrões organizacionais, todos os times Scrum devem segui-lo como requisito mínimo. Caso contrário, cabe ao Scrum Team criar um D.o.D. apropriado para o produto.

Os Developers têm a responsabilidade de aderir ao Definition of Done. Se houver múltiplos times Scrum trabalhando em conjunto no mesmo produto, eles devem definir e seguir coletivamente o mesmo D.o.D.

Exemplo da Definition of Done

A seguir um exemplo de uma Definition of Done (D.o.D.):

Importância do Definition of Done

O Definition of Done (D.o.D.) é essencial para criar um entendimento compartilhado sobre o trabalho realizado, tanto dentro da equipe Scrum quanto entre as partes interessadas. Ele impacta diretamente os seguintes aspectos:

Transparência e Qualidade

O D.o.D. fornece clareza sobre o que foi efetivamente concluído em cada incremento, criando confiança no trabalho da equipe e evitando mal-entendidos.

Evitando Retrabalho

Ao garantir que todos os critérios de qualidade sejam atendidos, o D.o.D. reduz a necessidade de revisões ou correções posteriores, otimizando o tempo da equipe.

Alinhamento em Múltiplas Equipes

Quando várias equipes Scrum trabalham no mesmo produto, é obrigatório que elas definam e sigam uma única Definition of Done. Isso assegura que todos os incrementos estejam em conformidade com os mesmos padrões de qualidade.

Adaptação a Padrões Organizacionais

Se a organização possui padrões estabelecidos para o D.o.D., todas as equipes devem segui-los como um requisito mínimo. Caso contrário, cada equipe Scrum tem a responsabilidade de criar uma definição que atenda às necessidades específicas do produto.

Diferença entre Definition of Done e Acceptance Criteria

A diferença entre o Definition of Done (D.o.D.) e os Critérios de Aceitação está no foco e no propósito de cada um deles.

O Definition of Done é um conjunto de critérios gerais e objetivos que define quando um incremento (ou funcionalidade) está finalizado e pronto para ser liberado. Ele foca na qualidade global e nos requisitos técnicos mínimos necessários para que o trabalho seja considerado completo. O D.o.D é válido para todos os itens do backlog e é definido pela equipe como um padrão global que promove transparência e consistência no trabalho.

Exemplo de uma D.o.D.:

• De acordo com os critérios de aceitação.
• Código revisado e aprovado.
• Testes unitários e de integração executados com sucesso.
• Funcionalidade implantada em um ambiente de homologação.
• Documentação técnica atualizada.
• Garantia de que os critérios de segurança foram atendidos.

Os Critérios de Aceitação são condições específicas para determinar se uma história do usuário ou item do Product Backlog atende aos requisitos funcionais e não funcionais descritos. Eles são definidos em conjunto pelo Product Owner e a equipe, geralmente antes do início do trabalho.

Para uma história de usuário como “Eu, como usuário, quero redefinir minha senha para recuperar o acesso ao sistema”:

• O usuário deve receber um e-mail com um link para redefinir a senha.
• O link deve expirar após 24 horas.
• A senha deve ter no mínimo 8 caracteres, com pelo menos uma letra maiúscula e um número.
• O sistema deve confirmar visualmente que a redefinição foi concluída.

Esses critérios são específicos para cada história ou funcionalidade e garantem que o resultado final atenda às necessidades do cliente ou usuário final.

Dessa forma:

• Critérios de Aceitação verificam se o trabalho resolve o problema ou atende à necessidade do usuário final. São específicos e focados na funcionalidade.
• O Definition of Done verifica se o trabalho foi concluído com qualidade, com todos os padrões técnicos e organizacionais aplicados.

Por exemplo, em um projeto de desenvolvimento de software:

1. Os Critérios de Aceitação asseguram que a funcionalidade “login do usuário” funciona conforme esperado.
2. O Definition of Done garante que o código do “login do usuário” foi revisado, testado e está pronto para produção.

Embora semelhantes, o Definition of Done e os Critérios de Aceitação têm propósitos distintos e são usados em momentos diferentes do processo de desenvolvimento. Enquanto o DoD é um padrão geral de qualidade e transparência, os Critérios de Aceitação focam em garantir que as histórias atendam aos requisitos específicos do cliente ou usuário final. Juntos, eles garantem entregas consistentes, funcionais e de alta qualidade.

Exemplos de Aplicação do Definition of Done em Diferentes Cenários

O Definition of Done (D.o.D.) é uma ferramenta versátil que pode ser aplicada em diversos contextos, desde projetos de tecnologia até produções criativas. Abaixo, exploramos como ele pode ser utilizado em cinco cenários distintos, demonstrando sua flexibilidade e impacto.

Scrum Team Individual

Para equipes Scrum trabalhando de forma autônoma em um projeto, o D.o.D. é fundamental para garantir a entrega de incrementos com qualidade e alinhados aos objetivos do produto. Por exemplo, uma equipe desenvolvendo um aplicativo de gestão financeira pode ter um D.o.D. que inclua:

• Código revisado e aprovado em peer review.
• Testes automatizados e manuais executados com sucesso.
• Funcionalidade validada pelo Product Owner.
• Atualização da documentação técnica para refletir as mudanças.

Esses critérios asseguram que a funcionalidade está pronta para uso e atende aos requisitos de qualidade.

Múltiplos Scrum Teams no Mesmo Produto

Em projetos grandes, onde vários times Scrum colaboram no desenvolvimento de um único produto, o D.o.D. deve ser padronizado para garantir consistência. Por exemplo, no desenvolvimento de um sistema integrado de e-commerce:

• Testes de integração realizados para verificar a interoperabilidade entre módulos.
• Critérios de segurança e conformidade aplicados uniformemente.
• Documentação consolidada que reflete o trabalho de todos os times.
• Deploy dos incrementos em um ambiente de homologação para validação conjunta.

Essa padronização evita conflitos e assegura que os incrementos de diferentes equipes possam ser integrados de maneira fluida e confiável.

Produtos de IT

No desenvolvimento de produtos de tecnologia, o D.o.D. é amplamente utilizado para garantir a entrega de soluções robustas. Considere, por exemplo, o desenvolvimento de uma aplicação de inteligência artificial:

• Modelo treinado com conjuntos de dados validados e documentados.
• Código otimizado e revisado por especialistas.
• Testes de precisão e desempenho executados com métricas estabelecidas.
• Deploy em um ambiente controlado para testes finais.

Esse D.o.D. assegura que a solução esteja pronta para produção e que os padrões técnicos e éticos foram respeitados.

Cena de um Filme

O D.o.D. também pode ser aplicado no setor de entretenimento, como na produção de uma cena de filme. Imagine uma cena de ação em um longa-metragem. O D.o.D. pode incluir:

• Roteiro revisado e aprovado pela equipe criativa.
• Filmagem realizada com todas as tomadas necessárias e em conformidade com o planejamento.
• Edição finalizada, com som, efeitos visuais e correção de cores ajustados.
• Aprovação do diretor e dos produtores.

Esses critérios garantem que a cena esteja pronta para ser integrada ao filme sem a necessidade de revisões adicionais.

Capítulo de um Livro

No universo literário, o D.o.D. pode ser usado para determinar quando um capítulo de um livro está completo. Para um romance de ficção, o D.o.D. pode incluir:

• Revisão ortográfica e gramatical realizada.
• Alinhamento do texto com a trama principal e subtramas do livro.
• Feedback de leitores beta integrado ao conteúdo.
• Aprovação final do autor e do editor.

Esse processo garante que o capítulo esteja bem estruturado, coeso e alinhado ao propósito narrativo do livro.

Níveis da Definition of Done

A Definition of Done ideal é aquela que traz um significado de pronto tanto para negócio quanto para a área técnica. Essa Definition of Done é também conhecida como Definition of Done Forte. Já uma Definition of Done que não seja o ideal e por consequência nos leva a revisitar o item posteriormente é conhecida como Definition of Done Fraca.

O Pete Stevens criou uma regra de avaliação de Definition of Done chamada de Levels of Done Explained e traduzida por Anderson Hummel para entender e melhorar sua “Definition of Done”. Produtos confiáveis, utilizáveis e valiosos são a base do sucesso. Comece de onde você está e melhore a partir daí. E lembre-se, o sucesso exige atenção aos resultados além do final da sprint.

Não Concluído

Não se engane. Se você ouvir as expressões, o item não está pronto:

Noventa por cento concluído: Como diz o ditado, os primeiros 90% do trabalho levam os primeiros 90% do tempo. Os 10% restantes levam os outros 90% do tempo!

Funciona no Meu Computador: como em “Funciona no meu computador, mas não tenho ideia se funciona em qualquer outro lugar”. Outra forma de dizer “não está pronto”.

Funcionando

Funcional (Functional): “validado contra nossos critérios de aceitação”. Esse é o primeiro passo para estar realmente pronto.

Confiável

Inspecionado (Inspected): A equipe revisou e melhorou o código para garantir que atende aos padrões de qualidade.

Integrado (Integrated): Todos os componentes do produto funcionam juntos.

Automatizado: Repositórios e conjuntos de testes garantem que ainda funciona mesmo após fazer alterações.

Utilizável

Implantável (Deployment Ready): Se deve ser implantado ou não é uma decisão comercial, não técnica.

Revisado (Reviewed): Revisado por Usuários e Clientes. Sua primeira linha de defesa contra a construção do que está errado e a confirmação da construção do que está correto.

Implantado (Deployed): Foi colocado em serviço ou está à venda e pode ser lançado para clientes ou usuários.

Valioso

Utilizavel (Usage): Lançado para clientes ou usuários (e você está medindo).

Resultado (Outcome): Alcançando os resultados desejados para negócios, usuários e o mundo. As suposições de valor para o negócio foram validadas (ou não).

Otimizado (Optimized): Muitas vezes, o primeiro passo no desenvolvimento é criar uma capacidade. Melhoria no ROI, usabilidade, confiabilidade, etc., pode exigir mais iteração na solução.

Definition of Done na prática

Avalie com os membros do Scrum Team e os Stakeholders sobre o significado de potencialmente entregável na perspectiva técnica e de negócios para uma primeira Sprint. Considere os seguintes critérios como um ponto de partida para potencialmente entregável:

Adicione mais critérios que se aplicam ao seu produto e remova os critérios que não se aplicam ao seu produto. Adicione mais detalhes ao que se aplica ao seu produto de forma facilitar a validação.

Atualizando o D.O.D. para uma Sprint posterior

A partir da D.o.D. atual avalie se o Scrum Team pode fazer todos os critérios para um item do Product Backlog em um único Sprint. Se sim, um forte D.o.D. é alcançado em um único Sprint. Se não, valide o conjunto máximo de critérios que pode ser feito em uma Sprint e aos poucos tente aproximar do que é ideal. Nesse caso, se tem uma D.o.D. fraca e você está criando TRABALHO NÃO TERMINADO.

Explore o que fazer com o TRABALHO NÃO TERMINADO

Esta sessão traduzido e adaptado do capitulo de Definition of Done do livro Large Scale Scrum do Craig Larman e Bas Vodde.

O TRABALHO NÃO TERMINADO é tudo aquilo que o Scrum Team deixa de fazer e que deveria ser feito para ser ter algo idealmente pronto. Como exemplo: Deploy em produção, teste de carga, teste de performance.

É um fato que o TRABALHO NÃO TERMINADO vai crescer com o tempo, que irá esconde riscos, e diminui a capacidade de entrega.

Abaixo quatro maneiras de gerenciar TRABALHO NÃO TERMINADO:

– Tornar a D.O.D. mais forte: A melhor maneira de lidar com o TRABALHO NÃO TERMINADO é evitar que ele ocorra ao buscar uma D.o.D. forte. Essa é a unica boa opção.

– Release Sprint: Uma ou vários sprints para que o Scrum Team resolva o TRABALHO NÃO TERMINADO. Isso esconde os riscos e diminui o tempo disponível para eventuais correções.

– O departamento de TRABALHO NÃO TERMINADO resolve: Departamento com pessoas especializadas realizam o TRABALHO NÃO TERMINADO. Isso normalmente causa atrasos, interrupções, riscos e reduz o aprendizado.

Pipelining para o TRABALHO NÃO TERMINADO: Ao final de cada sprint, o departamento TRABALHO NÃO TERMINADO finaliza o trabalho. (causar interrupções e conflitos com os membros do Scrum Team)

Conclusão

O Definition of Done é muito mais do que um simples checklist. Ele é uma ferramenta essencial para garantir qualidade, alinhamento e eficiência em qualquer projeto, seja na área de tecnologia ou em outros setores. Sua implementação promove clareza e confiança entre os membros da equipe, reduzindo o risco de falhas e entregas insatisfatórias.

Adotar um D.o.D. eficaz requer comunicação constante, alinhamento entre as partes interessadas e revisões periódicas para garantir que ele continue relevante. É uma peça-chave no quebra-cabeça da agilidade, fortalecendo a capacidade da equipe de entregar valor de forma contínua e consistente.