O que é Retrospectiva?

A Retrospectiva faz parte do Scrum desde suas primeiras versões documentadas, publicadas por Ken Schwaber e Jeff Sutherland a partir de 2010, mas a prática de refletir sobre o próprio trabalho em ciclos regulares é anterior ao Scrum. O Manifesto Ágil, de 2001, já trazia essa ideia como um de seus doze princípios: em intervalos regulares, o time reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.

Outros métodos ágeis desenvolveram práticas equivalentes de forma paralela. O Kanban, por exemplo, não tem um evento chamado Retrospectiva, mas prevê encontros de melhoria como a Retrospectiva do Time e, em contextos com múltiplos times, a Revisão do Fluxo. A ideia central, parar regularmente para inspecionar o próprio processo, é comum a praticamente todos os frameworks ágeis, cada um com seu próprio nome e formato para o evento.

O Scrum Guide manteve a Retrospectiva praticamente estável em conceito ao longo das revisões, reforçando-a como o quarto evento formal do framework, sempre posicionado logo após a Sprint Review e antes do início da Sprint seguinte.

Se a Sprint Review inspeciona o produto, a Retrospectiva inspeciona o time. É o único evento do Scrum dedicado inteiramente a olhar para dentro: como estamos trabalhando juntos, e o que podemos fazer diferente.

Quem participa. Todo o Time Scrum: Product Owner, Scrum Master e Desenvolvedores. Pessoas externas, como gestores ou clientes, podem ser convidadas para um encontro específico, mas com cuidado, porque a presença de quem está fora do time pode inibir uma conversa sincera sobre dificuldades internas.

Quando acontece. Sempre ao final da Sprint, depois da Sprint Review e antes da próxima Sprint Planning. Acontece mesmo quando o time não conseguiu entregar nada, ou quando a Sprint terminou mal, situações que costumam gerar exatamente os assuntos mais importantes para discutir, muito mais do que uma Sprint tranquila em que tudo saiu como planejado. Times com Sprints de uma semana costumam deixar a Retrospectiva fixa em um horário, como toda sexta às 10h, o que facilita a organização e evita a tentação de remarcar quando a semana aperta.

Duração. O timebox é proporcional à duração da Sprint. Para Sprints de um mês, o Scrum Guide sugere até três horas; para Sprints mais curtas, o tempo tende a ser proporcionalmente menor. Um time com Sprint de uma semana pode rodar uma Retrospectiva eficaz em 45 minutos.

O arco de uma boa Retrospectiva. Um formato amplamente usado, inspirado no livro *Agile Retrospectives* de Esther Derby e Diana Larsen, segue cinco etapas: preparar o terreno (criar um ambiente seguro para falar), coletar dados (o que aconteceu, fatos e percepções), gerar insights (por que aconteceu), decidir o que fazer (ações concretas) e fechar a retrospectiva (consolidar o combinado). Pular direto para "o que fazer" sem coletar dados nem gerar insights costuma produzir ações superficiais.

O resultado esperado. Ao menos uma melhoria de alto impacto, identificada e registrada, que muda a forma como o time trabalha na Sprint seguinte, de um jeito que qualquer pessoa do time consegue nomear em uma frase. Não é sobre listar todos os problemas: é sobre escolher o que vale a pena mudar agora, com dono e prazo claros, para que a ação de fato aconteça.

Melhoria contínua não se limita ao evento. O Scrum Guide e o próprio Manifesto Ágil deixam claro que, se o time perceber uma melhoria possível entre uma Retrospectiva e outra, ela deve ser feita na hora, sem esperar o próximo ciclo. A Retrospectiva existe para forçar essa pausa quando ela não acontece naturalmente, não para ser a única oportunidade de melhorar.

Verifique se a mudança ajudou. Uma ação escolhida na Retrospectiva é hipótese de melhoria, não prova antecipada de solução. Declare que sinal indicará avanço: menos espera por revisão, menos defeitos reabertos ou conversas de refinamento mais claras, por exemplo. Na Sprint seguinte, observe o trabalho real e pergunte se o efeito previsto apareceu. Se não apareceu, investigue em vez de carregar a mesma ação como pendência eterna. Algumas melhorias exigem apoio de outra área ou decisão de liderança; registre a dependência e torne-a visível, sem responsabilizar apenas o time por algo fora de sua autoridade. A Retrospectiva também pode reconhecer práticas que funcionaram e devem ser mantidas. Esse equilíbrio evita que o encontro vire uma lista de reclamações e ajuda pessoas a perceber que falar abertamente produz decisões e acompanhamento, mesmo quando o problema não se resolve em uma única Sprint.

Imagine um time de suporte técnico que também constrói funcionalidades para o próprio produto de atendimento, trabalhando em Sprints de duas semanas. Na Retrospectiva, o Scrum Master abre perguntando: "o que aconteceu nesta Sprint que vale a pena olhar de perto?".

O time levanta dados: das oito horas de trabalho por dia, em média três foram consumidas por interrupções de suporte urgente, não planejadas na Sprint. Ninguém tinha esse número antes, só a sensação de "estamos sempre interrompidos". Ver o número escrito muda o tom da conversa.

Na etapa de gerar insights, o time discute por que isso acontece: não existe critério combinado para o que é "urgente de verdade", então qualquer chamado que chega direto para um Desenvolvedor específico vira prioridade automática. Alguém lembra que times de suporte costumam ter uma pessoa de plantão, e pergunta se isso faria sentido aqui.

O time decide uma ação: nas próximas duas Sprints, uma pessoa por semana assume o papel de "plantonista", cuidando de interrupções, enquanto o resto do time protege o foco da Sprint. Define quem começa, e combina revisar o resultado na próxima Retrospectiva, comparando as horas de interrupção com esta Sprint.

Duas semanas depois, o time volta com dado novo: as interrupções fora do plantonista caíram de três horas por dia para quase zero, e o plantonista consegue lidar com boa parte dos chamados sem precisar tirar outras pessoas do fluxo. A ação funcionou, e o time decide manter o rodízio como prática fixa, sem precisar revisitar isso toda Retrospectiva.

Repara no que tornou essa Retrospectiva eficaz: o time não discutiu soluções antes de ter dados. A sensação vaga de "estamos sempre interrompidos" virou um número concreto, três horas por dia, e só depois disso a conversa sobre causas fez sentido. A ação escolhida também tinha um critério claro de sucesso combinado de antemão, o que tornou fácil avaliar, duas semanas depois, se ela funcionou ou não.

Os três eventos respondem perguntas diferentes: a Daily pergunta "estamos no caminho certo hoje?", a Review pergunta "o que construímos gera valor?", e a Retrospectiva pergunta "como podemos trabalhar melhor amanhã?". Confundir os três costuma acontecer quando a Retrospectiva vira uma segunda Daily, focada em status de tarefas, em vez de olhar para padrões de comportamento e processo ao longo de toda a Sprint, que raramente aparecem numa única pergunta de 15 minutos.

Cursos K21 recomendados