Definição de “concluído” (DoD): lista de verificação e exemplos
A definição de “concluído” (DoD) é uma lista de verificação que cada história deve cumprir antes de ser entregue. Exemplos de listas de verificação, como elaborar a sua e a diferença entre DoD e critérios de aceitação.
A definição de “concluído” (DoD) é uma breve lista de verificação que a equipe concorda que cada história deve cumprir antes de ser considerada concluída: revisada, testada, mesclada, implantada e aceita. Trata-se de um padrão único para toda a equipe. Os critérios de aceitação são específicos para cada história; a definição de “concluído” é global. Confundir os dois é o que faz com que “concluído” passe a significar, sem que se perceba, “funciona no meu computador”.
Toda equipe já sentiu a diferença entre “o desenvolvedor diz que está pronto” e “está realmente pronto para ser lançado”. A definição de “concluído” elimina essa lacuna. Você concorda com ela uma vez e a aplica a cada sprint, independentemente do que cada história individual envolva. Sem ela, “concluído” é uma opinião pessoal, e a diferença vem à tona na demonstração ou, pior ainda, na produção.
O que significa a definição de “concluído” no Scrum
O Guia do Scrum define isso como “uma descrição formal do estado do Incremento quando ele atende aos critérios de qualidade exigidos para o produto”. Em termos simples, a definição de “concluído” é o compromisso associado ao Incremento, um dos três artefatos do Scrum. O trabalho que atende a essa definição passa a fazer parte do Incremento. O trabalho que não a atende não pode ser lançado nem apresentado na revisão do sprint; ele volta para o backlog do produto.
Se a sua organização já define o que é considerado “concluído”, todas as equipes utilizam essa definição como requisito mínimo e podem complementá-la. Caso contrário, a equipe elabora sua própria definição. A ideia não se limita ao Scrum: as equipes de Kanban costumam elaborar essa mesma lista como diretriz para transferir o trabalho para a coluna final.
Exemplos de definição de “concluído”
Exemplo de lista de verificação de “concluído”: uma equipe de software
Um ponto de partida viável para uma equipe que está lançando um aplicativo web:
- Os critérios de aceitação foram atendidos e verificados.
- O código foi revisado e incorporado ao ramo principal.
- Testes automatizados criados e aprovados; nenhum novo teste instável.
- Não há regressões conhecidas nem bugs críticos pendentes relacionados a essa tarefa.
- A documentação e o histórico de alterações foram atualizados nos casos em que a alteração afeta diretamente o usuário.
- Implantado no ambiente de teste e submetido a testes de validação.
- O proprietário do produto aprovou a proposta.
Adote isso e, em seguida, adapte-o ao que sua equipe realmente vai colocar em prática. Uma definição de “concluído” com um item que ninguém verifica é pior do que uma definição curta. Isso faz com que a equipe passe a tratar toda a lista como algo meramente decorativo. Mantenha-a em uma única tela e certifique-se de que cada item seja verificável.
Exemplo de definição de “concluído”: uma equipe que não lança código
A mesma ideia se aplica a uma equipe de marketing, de conteúdo ou de design. A definição de “concluído” de uma equipe de conteúdo poderia ser a seguinte:
- Os critérios de aceitação do briefing foram atendidos.
- Editado por outra pessoa que não o autor.
- Fatos, números e links verificados.
- Noções básicas de acessibilidade atendidas: texto alternativo, ordem dos títulos, contraste legível.
- Aprovado por quem o solicitou.
- Publicado ou repassado, e registrado em um local onde a equipe possa acessá-lo.
Níveis de história, sprint e lançamento
O Scrum exige uma única definição de “concluído” para o Incremento. Na prática, muitas equipes agrupam as verificações de acordo com o local onde elas ocorrem naturalmente:
| Nível | Aplica-se a | Itens típicos |
|---|---|---|
| História | Cada item da lista de pendências | Código revisado, testes aprovados, critérios de aceitação atendidos, aprovado pelo proprietário do produto |
| Sprint | O Increment como um todo | Integrado no branch principal, conjunto de testes de regressão aprovado, implantado no ambiente de teste |
| Comunicado | O que chega aos clientes | Notas de lançamento redigidas, verificações de segurança e desempenho realizadas, equipe de suporte informada |
Mantenha o nível da história como referência principal na lista. Se uma verificação só puder ser feita no momento do lançamento, anote isso na lista também, para que ninguém marque uma história como concluída presumindo que outra pessoa irá identificar essa lacuna posteriormente.
Como redigir uma definição de “concluído”
- Comece pelo que sempre acaba escapando. Analise os últimos sprints: os bugs encontrados após a conclusão, as histórias que voltaram para revisão, o trabalho que ficou para o próximo sprint. Cada um deles aponta para uma etapa que está faltando.
- Elabore-a com toda a equipe. As pessoas que realizam o trabalho chegam a um acordo em uma única sessão, com a facilitação do scrum master e a presença do product owner na sala. Uma lista imposta de fora é algo que a equipe não defenderá sob a pressão dos prazos.
- Faça com que cada linha seja verificável. “Testado” é uma impressão; “testes automatizados escritos e aprovados na integração contínua” é uma verificação. Se duas pessoas puderem discordar sobre se uma linha foi cumprida, reescreva-a.
- Limite-se ao que você vai exigir agora. Começaríamos com cinco a oito itens. Adicione os itens mais ambiciosos quando a equipe estiver realmente em condições de cumpri-los.
- Coloque onde o trabalho é feito. Uma lista de verificação no modelo do ticket ou na coluna “concluído” do quadro é utilizada. Uma página na wiki acaba sendo esquecida.
- Analise isso na retrospectiva. Quando a mesma lacuna aparecer duas vezes, acrescente uma linha. Quando uma linha for marcada sem que ninguém a tenha verificado, pergunte se ela ainda merece estar ali.
Definição de “concluído” versus critérios de aceitação
Essa é a distinção com a qual as equipes mais se confundem. Os critérios de aceitação para uma história de login são específicos para o login: credenciais corretas levam você ao painel, três tentativas erradas bloqueiam a conta. A definição de “concluído” (revisado, testado, implantado) é idêntica para a história de login, a história de pesquisa e a história de cobrança. Os critérios são locais e respondem à pergunta “construímos a coisa certa?”. A definição de “concluído” é global e responde à pergunta “alguma parte do nosso trabalho está pronta para ser entregue?”. Uma história não está concluída até que passe por ambas as etapas.
Definição de “pronto” versus definição de “concluído”
São como suportes de livro, não gêmeos simétricos. A definição de “pronto” permite que uma história entre no sprint: pequena o suficiente, clara o suficiente, estimada. A definição de “concluído” permite que o trabalho finalizado saia. “Pronto” diz respeito à história; “concluído” diz respeito ao trabalho. Equipes que têm apenas um desses critérios geralmente se concentram no “pronto” (porque histórias não prontas chamam muita atenção) e deixam o “concluído” de lado discretamente — e é assim que se acumulam as histórias que transbordam para o próximo sprint e as que estão “90% concluídas”.
As três listas de verificação deixam de se confundir assim que você percebe o que cada uma delas controla:
| Definição de “pronto” | Critérios de aceitação | Definição de “concluído” | |
|---|---|---|---|
| Escopo | Global: cada história | Notícia local | Global: cada história |
| Portões | Entrada na sprint | O próprio desfecho da história | Saída do sprint |
| Respostas | ”Podemos começar?" | "Será que criamos a coisa certa?" | "Isso pode ser enviado?” |
| De propriedade de | Equipe, junto com o proprietário do produto | Responsável pelo produto, junto com a equipe | A equipe |
Quem define o que significa “concluído”?
A equipe é que escreve; a equipe é que faz valer. O scrum master facilita, e o product owner dá sua opinião sobre o padrão de aceitação, mas são os engenheiros que decidem o que “concluído” significa tecnicamente, porque um “concluído” mal definido é uma dívida que eles pagam, não a gerência. Reavalie isso em uma retrospectiva quando a mesma lacuna continuar aparecendo; esse é o sinal de que falta uma regra.
Como a definição de “concluído” altera suas estimativas
Os story points dimensionam o trabalho até o momento em que está “concluído”, e não até a “conclusão do código”. Portanto, a definição de “concluído” está incorporada em cada estimativa. Adicione uma linha como “testado quanto ao desempenho” e cada história ficará um pouco maior. Quando a lista mudar, verifique novamente suas histórias de referência na próxima sessão de planejamento; caso contrário, a velocidade cairá por um motivo que ninguém saberá explicar.
O que dá errado
A definição de “concluído” vira um cartaz. É afixada no wiki da equipe, repetida durante a integração de novos membros e ignorada sob a pressão dos prazos: “vamos escrever os testes no próximo sprint”. Dois sprints depois, a dívida de testes se torna estrutural e a definição é uma ficção. Quando “concluído” é vago, a velocidade é inflada: a equipe acumula pontos por um trabalho que não está realmente pronto para ser entregue, e a previsão, discretamente, deixa de ter qualquer significado.
A solução não é uma lista mais longa; é uma lista mais curta, na qual a equipe se manterá firme. Uma definição de “concluído” só é válida na medida em que você esteja disposto a não marcar uma tarefa como concluída por ela não ter atendido a um desses critérios.
Os critérios de aceitação definem o ponto de conclusão da história. A definição de “concluído” define o ponto de conclusão da equipe. Mantenha-a curta o suficiente para que você realmente a aplique. Um ponto de conclusão que não é aplicado é apenas burocracia.
Perguntas frequentes
Qual é a definição de “concluído” no método ágil?
A definição de “concluído” (DoD) é uma lista de verificação única que toda história deve cumprir antes de ser considerada concluída: normalmente, testada, revisada, mesclada, documentada e implantada no ambiente de teste. Trata-se de um padrão comum para toda a equipe, e não de uma lista específica para cada história, e existe para que “concluído” tenha sempre o mesmo significado, independentemente de quem o diga.
Qual é a diferença entre a definição de “concluído” e os critérios de aceitação?
A definição de “concluído” é global, sendo o mesmo critério de aprovação para todas as histórias. Os critérios de aceitação são locais, específicos para cada história. Os critérios de aceitação definem o que esse recurso deve fazer; a definição de “concluído” define o que significa “pronto para lançamento” para qualquer trabalho produzido pela equipe. Uma história precisa ser aprovada em ambos.
O que é uma lista de verificação de “definição de concluído”?
Uma lista curta e explícita de condições aplicadas a cada story: código revisado e integrado, testes escritos e aprovados, sem regressões conhecidas, documentação atualizada, implantado em um ambiente de teste e aceito pelo product owner. Os itens exatos variam de acordo com a equipe, mas a lista deve caber em uma tela e cada linha deve poder ser verificada.
Qual é a diferença entre a definição de “pronto” e a definição de “concluído”?
Os critérios de “pronto” marcam a entrada no sprint; são os requisitos que uma tarefa precisa atender antes que a equipe se comprometa com ela. Os critérios de “concluído” marcam a saída do sprint; são os requisitos que o trabalho concluído precisa atender antes de ser entregue. “Pronto” significa que a tarefa está bem definida; “concluído” significa que o trabalho está pronto para ser lançado.
Como se redige uma definição de “concluído”?
Comece pelo que sempre fica de fora: os bugs, o retrabalho e o acúmulo dos últimos sprints. Chegue a um acordo sobre a lista com toda a equipe, redija cada item de forma que tenha uma resposta do tipo “sim” ou “não”, reduza-a ao que você realmente vai aplicar e coloque-a onde o trabalho é feito, como no modelo de ticket. Depois, revise-a na retrospectiva sempre que algo passar despercebido.
Quem define o que significa “concluído”?
A equipe de desenvolvimento é responsável por isso, geralmente com a facilitação do scrum master. O product owner dá sua opinião sobre o padrão de aceitação, mas são as pessoas que realizam o trabalho que decidem o que “concluído” significa tecnicamente, pois são elas que pagam o preço quando isso é definido de forma vaga.
Leitura relacionada
- Estimativa ágil: o guia completo: o centro de informações sobre tudo o que há para saber aqui.
- Critérios de aceitação: o teste por história com o qual a definição de “concluído” costuma ser confundida.
- Definição de “pronto”: o portão de entrada na outra extremidade do sprint.
- Erros no Planning Poker: como um “concluído” vago inflaciona a velocidade.