Retrospectiva de Definition of Ready

Garanta que suas histórias estejam prontas antes da sprint começar.

Experimente esta apresentação ao vivo retrospectiva

Nossa DoR atual

Como está a nossa Definition of Ready hoje?

A gente diz que uma história está pronta quando tem critérios de aceitação, mas acho que nem todo mundo concorda sobre o que são 'bons' critérios de aceitação.
Nossa DoR inclui: história de usuário escrita, critérios de aceitação definidos, história estimada e dependências identificadas.
Sinceramente, não sei se temos uma DoR formal. A gente só puxa o que estiver no topo do backlog.
Quando funciona

O que dá certo quando as histórias atendem à nossa DoR?

Quando as histórias estão bem dimensionadas e têm critérios de aceitação claros, o planejamento da sprint fica muito mais rápido. Terminamos em menos de uma hora.
Percebo que temos bem menos bloqueios no meio da sprint quando as dependências são apontadas logo no refinamento.
O time se sente mais seguro para se comprometer com as histórias quando todo mundo teve a chance de tirar dúvidas antes da sprint começar.
Quando dá errado

Que problemas surgem quando as histórias não estão realmente prontas?

Na última sprint puxamos uma história sem critérios de aceitação e ela virou três dias de vai e volta com o PO.
Histórias sem escopo claro acabam sendo 'concluídas' de jeitos diferentes por cada dev, e aí o QA encontra inconsistências.
Vivemos descobrindo dependências no meio da sprint que nos travam por dias. Isso deveria ser pego no refinamento.
Melhorar nossa DoR

Que mudanças devemos fazer para fortalecer a nossa DoR?

Deveríamos colocar um checklist no template de ticket do Jira para nada ficar de fora antes de uma história ser marcada como pronta.
Queria que a gente combinasse que nenhuma história entra na sprint sem pelo menos uma sessão de refinamento com o time inteiro presente.
Precisamos de uma regra clara: se a história não tiver critérios de aceitação 48 horas antes do planejamento, ela não entra.

O que é a Retrospectiva de Definition of Ready?

Uma sprint flui melhor quando o trabalho que entra nela já estava pronto antes do planejamento começar. A Definition of Ready (DoR), ou Definição de Preparado, é a lista de critérios de entrada que um item do backlog precisa atender antes de ser puxado para uma sprint, como critérios de aceitação, uma estimativa e dependências conhecidas. A Retrospectiva de Definition of Ready verifica se essa lista está cumprindo o seu papel. O quadro tem quatro colunas. Nossa DoR atual mostra quais são os critérios de fato hoje, que muitas vezes mudam de pessoa para pessoa. Quando funciona reúne exemplos de histórias preparadas que andaram sem problemas. Quando dá errado trata do que aconteceu quando trabalho despreparado entrou em uma sprint. Melhorar nossa DoR é onde vocês combinam as mudanças. Use quando o planejamento sempre se estende, as histórias travam no meio da sprint ou ninguém olha a DoR há meses. Funciona tanto para times Scrum quanto Kanban. No TeamRetro, as pessoas podem adicionar ideias de forma anônima, então os problemas do refinamento aparecem mesmo quando são incômodos de levantar.

Formato da Retrospectiva de Definition of Ready

Nossa DoR atual

Como está a nossa Definition of Ready hoje?

Peça para cada pessoa escrever quais acha que são os critérios atuais. Muitos times têm uma DoR informal ou que nunca foi escrita, e as diferenças entre as respostas mostram por onde começar.

Quando funciona

O que dá certo quando as histórias atendem à nossa DoR?

Procure sprints ou histórias específicas em que estar preparado fez diferença, como um planejamento curto ou uma história concluída sem precisar correr atrás de ninguém. Esses exemplos mostram ao time por que vale a pena manter a DoR.

Quando dá errado

Que problemas surgem quando as histórias não estão realmente prontas?

Esta coluna costuma ser a mais reveladora. Peça exemplos de histórias específicas que entraram na sprint sem atender à DoR e o que aconteceu depois. Procure padrões: as mesmas lacunas se repetem ou afetam sempre os mesmos tipos de história?

Melhorar nossa DoR

Que mudanças devemos fazer para fortalecer a nossa DoR?

Combinem mudanças concretas, como incluir ou remover critérios, mudar a forma de fazer o refinamento ou ajustar as ferramentas. O objetivo é sair com 1–3 mudanças para testar na próxima sprint.

Quando utilizar esta análise retrospectiva

  • O time vive esbarrando em bloqueios no meio da sprint, aumento de escopo ou histórias que não cabem na sprint, o que geralmente indica que o trabalho não estava pronto quando foi planejado.
  • O planejamento da sprint se estende ou fica caótico porque o backlog não foi refinado antes de o time se comprometer.
  • Vocês estão recebendo pessoas novas no time e querem registrar o que 'pronto' significa para vocês.
  • O time tem uma Definition of Ready, mas não a revisa há algum tempo, e ela pode não refletir mais como vocês trabalham hoje.
  • Depois de uma sprint difícil em que requisitos pouco claros ou informações faltando causaram atrasos ou retrabalho.

Perguntas sugeridas para quebra-gelo

  • Se o seu backlog fosse uma cozinha, ele seria uma despensa organizada e bem abastecida ou uma geladeira caótica cheia de sobras misteriosas? Por quê?
  • Qual é aquela coisa que você queria saber no começo de uma tarefa, mas que sempre acaba descobrindo só na metade?

Quer um exercício de aquecimento que sua equipe faça, e não apenas responda em voz alta? Veja quebra-gelos gratuitos →

Ideias e dicas para sua reunião de retrospectiva

  • Compartilhe a DoR atual antes da sessão para que as pessoas cheguem com exemplos reais.
  • Fale de lacunas no processo, não de erros individuais, para que as pessoas possam contar o que deu errado sem culpa.
  • Defina um tempo para cada coluna. Discussões sobre a DoR facilmente viram refinamento de histórias específicas, então mantenha a retro focada nos critérios em si.
  • Combinem de 1–3 mudanças por sessão. Uma DoR que tenta cobrir tudo fica longa demais para ser seguida.
  • Envolva o time inteiro, não só o Scrum Master ou o Product Owner. Devs, QA e designers sentem o impacto de histórias despreparadas de formas diferentes.
  • Na próxima retrospectiva, verifique se as mudanças deixaram o planejamento e a entrega mais fáceis.

Perguntas frequentes

O que é uma retrospectiva de Definition of Ready?
É uma retrospectiva que revisa os critérios de entrada do time para os itens do backlog. O quadro aborda a DoR atual, o que funciona quando as histórias a atendem, o que dá errado quando não atendem e o que mudar.
Qual é a diferença entre Definition of Ready e Definition of Done?
A Definition of Ready define os critérios de entrada que um item do backlog precisa atender antes de entrar em uma sprint. A Definition of Done define os critérios de saída para considerar o trabalho concluído. Esta retrospectiva trata da primeira.
Com que frequência um time deve fazer uma retrospectiva de Definition of Ready?
Faça depois de uma sprint difícil com requisitos pouco claros, quando entrarem pessoas novas no time ou a cada poucos meses para verificar se a DoR ainda reflete como o time trabalha.
A Definition of Ready faz parte do Scrum?
Não. O Guia do Scrum define a Definition of Done, mas não a Definition of Ready, que muitos times Scrum adotam por conta própria. Mantenha-a leve para que não vire uma barreira que bloqueia trabalho útil.
Quanto tempo leva uma retrospectiva de Definition of Ready?
Cerca de 45 a 60 minutos para a maioria dos times. Mantenha a discussão nos critérios em si, ou ela vira uma sessão de refinamento.

Modelos relacionados

Retrospectiva do Dia Mundial da Saúde Mental

Converse abertamente sobre o que pesa no seu time e o que ajuda.

Retrospectiva Big Bang Blast

Revisite sua sprint, da primeira faísca às novas galáxias.

Retrospectiva Ada Lovelace

Celebre as vitórias no código e corrija os bugs do seu processo.

Retrospectiva Reddit Rewind

Relembre o ano do seu time em upvotes e downvotes.

Pronto para conduzir essa retrospectiva?Experimente esta apresentação ao vivo retrospectiva