Qual a diferença entre Definição de Preparado, Pronto e Critérios de Aceitação?

Compartilhe:

Nesse mundo da agilidade temos algumas confusões com as nomenclaturas de alguns artefatos. DoD, DoR, DoT, Critérios de Aceitação. Nós gostaríamos de trazer neste artigo algumas definições importantes para ajudar o seu time. 

Definition of Ready(DoR) – Definição de Preparado

Esse é um artefato comum para muitos times que utilizam o Scrum, porém não é apresentado no Guia do Scrum. Ele é um item único para todos os itens de trabalho. Funciona como uma checklist criada pelo Time Scrum. Ele avalia o item para verificar se ele pode ou não entrar na etapa de construção de incrementos na Sprint. 

Exemplo: 

  • A demanda está escrita no formato de História de Usuário
  • O tamanho estimado da demanda é de no máximo 20 pontos de história
  • Há orçamento disponível para a execução da demanda
  • Os recursos de acesso aos dados foram concedidos para os desenvolvedores

Definition of Done (DoD) – Definição de Pronto

Esse é um artefato Scrum e no Guia do Scrum é definido como: “uma descrição formal do estado do Incremento quando ela atende às medidas de qualidade exigidas para o produto.

No momento em que um item do Product Backlog atende a Definição de Pronto, um incremento nasce”

Ken Schwaber e Jeff Sutherland, O Guia do Scrum 2020, p.13.

Assim como a Definição de Preparado, o DoD funciona como uma checklist que avalia se os itens de trabalho entregues pelo Time Scrum estão realmente prontos. O objetivo é evitar o famoso: Está pronto, só falta testar!

Algumas empresas ou unidades da organização estabeleçam um DoD único para garantir a qualidade do item que está sendo entregue. Nesse caso, os times devem respeitar esse DoD e podem acrescentar itens que acharem pertinentes. 

Exemplo:

  • Os testes automatizados não apresentaram erros
  • A cobertura de testes em funcionalidades críticas é de 100%
  • O item está disponível para uso do cliente
  • A documentação do incremento está guardada no repositório
  • O gerente da área foi avisado sobre a liberação do incremento

Definition of Transition (DoT) – Definição de Transição 

Uma das práticas do Kanban é tornar as políticas explícitas. Como ele não necessariamente tem uma Sprint, como podemos garantir que estamos entregando um produto com a qualidade desejada? Através da Definição da Transição. Ela é um checklist que está em cada transição de etapa. Veja o quadro abaixo

Um quadro de mapeamento de fluxo de valor dividido em 11 etapas cada divisão com sua definição de transição: Backlog, Detalhamento, Refinamento, Orçamentação, Disponibilização de Recursos, Priorização, Desenvolvimento, Testes e Qualidade, Disponibilização, Comunicação e Entregue. Diversos post-its espalhados nas colunas, porém o número é irrelevante.
Quadro de Mapeamento de fluxo de valor com os DoTs para cada etapa.

Um exemplo de DoT de Detalhamento para refinamento poderia ser: A demanda está escrita no formato de História de Usuário. De refinamento para orçamentação: O tamanho estimado da demanda é de no máximo 20 pontos de história. De Testes e Qualidade para Disponibilização: 

  • Os testes automatizados não apresentaram erros
  • A cobertura de testes em funcionalidades críticas é de 100%
  • A documentação do incremento está guardada no repositório

Perceba que o DoT funciona como se eu pegasse o DoR e o DoD e diluísse nas diversas etapas do meu fluxo de valor. 

É o mesmo quadro anterior com a definição de transição para cada etapa, porém agora entre a Etapa de Disponibilização de Recursos e Priorização está marcado o Ponto de Comprometimento. Antes deve, todas as etapas são o Upstream e após ele, todas as etapas são downstream.
Somatório dos DoT no Upstream equivale ao DoR e o somatório de DoT do Downstream equivale ao DoD.

Critérios de Aceitação

Os critérios de aceitação são diferentes. Eles são únicos para cada item de trabalho que estamos criando. A responsabilidade de criação dele, assim como todos os outros combinados, é do Time Scrum. Muitas vezes vemos essa atividade “delargada” para o Product Owner ou para o Testador / Quality Assurance (QA) do time. Essa não era a intenção de Mike Cohn quando escreveu sobre o tema em User Story Applied. O objetivo é criar de forma colaborativa um combinado entre desenvolvedores, testadores e Product Owner que garanta que todos compreendam se espera quando o item de trabalho for concluído.

Imagine a seguinte história de usuário: Eu, enquanto Bernardo Bibliotecário, desejo cadastrar um novo livro na biblioteca, para poder disponibilizá-lo para empréstimo. 

A princípio parece algo trivial. Entretanto, o que acontece caso o livro já exista, cadastra mais um exemplar ou dá uma mensagem de erro? O que acontece se o bibliotecário informar dois títulos iguais com ISBN diferentes? O autor deve estar cadastrado previamente ou pode cadastrar na hora? Essas perguntas podem ser respondidas justamente através dos critérios de aceitação, dessa forma não ficará nada subentendido e as expectativas serão explicitadas.

Não existe uma única forma de escrever critérios de aceitação, mas uma bem popular é o Desenvolvimento Guiado por Comportamento, mais conhecido pelo nome inglês Behavior-driven development (BDD) proposto por Dan North. O formato é bem simples. Cada item de trabalho (história de usuário) pode ter diversos cenários. Leve em consideração apenas cenários relevantes para o negócio. Coisas do tipo testar se 31 de fevereiro é uma data válida, verificar se o nome possui mais de 2 letras, embora importantíssimos, não farão parte dos critérios de aceitação para não ficar algo muito extenso e cansativo. O formato é:

Cenário: <O que desejamos avaliar>

Dado <condições necessárias para que possamos realizar a ação>

Quando <evento que dispara a ação>

Então <resultado esperado da ação>

Um exemplo:

Cenário: Cadastrar o mesmo livro duas vezes

Dado que já há um livro com o ISBN 979884700493-0 cadastrado

Quando o bibliotecário cadastrar outro livro com o mesmo ISBN

Então o sistema informará que esse livro já está cadastrado.

Há inclusive ferramentas que automatizam os testes com BDD como Cucumber e Specflow caso você queira e tenha conhecimento para tal. 

Quem é o responsável?

O responsável por todos esses artefatos é o time. Todos são acordos e como qualquer acordo, a colaboração é essencial. De todos esses, a maior confusão acontece com os critérios de aceitação. Muitos acham que o Product Owner é o único responsável por criá-los. Isso não é verdade. Mesmo porque quem desenvolve acaba percebendo critérios que alguém com foco no negócio não percebe. O contrário também é verdade. Por isso é necessário uma discussão em conjunto para uma boa construção desses critérios.

Quer saber mais sobre isso, veja o nosso treinamento de Certified Scrum Product Owner® (CSPO).

Sobre o autor(a)

Trainer na K21

Avelino Ferreira é formado e mestre em Ciência da Computação. Teve uma longa trajetória na TI, começando como programador e chegando a gestor de diversos times de criação de produtos digitais. Conheceu e começou a adotar as melhores prática de de Métodos Ágeis em 2008. Desde então, se dedica a auxiliar outras empresas na construção da cultura ágil. Atualmente, é Consultor e Trainer na K21

Artigos relacionados

Após terminar de ler o livro Ruído de Daniel Kahneman, decidi reler alguns clássicos que não olhava há algum tempo. Dentre eles, Rápido e Devagar do mesmo autor e Pensando em Sistemas de Daniela Meadows. Não pude deixar de perceber…

O Guia do Scrum fala sobre o refinamento do Product Backlog: “O Product Backlog é refinado conforme necessário” (p. 9). Todavia ele não descreve exatamente o que é o refinamento. Uma reunião, uma atividade, um processo. Neste artigo vamos jogar…

Marcos Garrido, Sócio-fundador e Trainer na K21

Existem muitas formas de organizar as métricas de seu produto / empresa. Aqui neste blog já escrevemos sobre as Métricas do Pirata, Fit For Purpose (F4P) e Métricas nas Quatro Áreas de Domínio da Agilidade. Todavia, agora, queremos falar sobre…

Após alguns anos desenvolvendo produtos e ajudando outras empresas a fazer tal, gostaria de listar com vocês alguns erros comuns que percebi ao longo dessa jornada. Olhando para as 4 Áreas de Domínio da Agilidade (Negócio, Cultural, Organizacional e Técnica)…