Modelo de Retrospetiva de Sprint para Equipas de Engenharia
Por que a maioria das retros não produz mudança
As retrospetivas de sprint têm um problema estrutural que os modelos não resolvem: as equipas geram ideias de melhoria mas não as reveem. A retro produz cinco itens de ação. A próxima retro abre com uma tela em branco. Os mesmos problemas ressurgem.
O modelo abaixo incorpora a revisão no início para que não possa ser saltada. Essa única mudança faz mais pela eficácia da retro do que qualquer ajuste de formato.
A pauta (copiar e colar)
Duração: 60 minutos para um sprint de 2 semanas; 45 minutos para um sprint de 1 semana
Formato: Facilitado, com um quadro assíncrono partilhado (Miro, FigJam, Notion — à sua escolha)
Secção 1 — Revisão dos itens de ação (10 min)
- Leia os itens de ação do sprint anterior um a um
- Marque cada um: Feito / Em progresso / Abandonado (motivo breve para os abandonados)
- Avance os itens incompletos; não os rediscuta agora
Secção 2 — Snapshot de dados (5 min)
- Velocidade do sprint vs. objetivo
- Trabalho não planeado que excedeu um dia
- Incidentes ou eventos de on-call
- Alterações de âmbito a meio do sprint
- Coloque os dados no ecrã sem discussão ainda
Secção 3 — O que correu bem (10 min)
- A equipa adiciona itens de forma assíncrona antes da reunião ou nos primeiros 3 minutos
- Discuta os 2 a 3 principais; salte itens com concordância óbvia
- Não gaste tempo em coisas que não são acionáveis
Secção 4 — O que melhorar (15 min)
- Mesmo formato: input assíncrono, discuta os itens de maior sinal
- Para cada item: ocorrência pontual ou padrão recorrente? Apenas padrões tornam-se itens de ação
- O papel do facilitador é transformar "isto foi frustrante" em algo específico e modificável
Secção 5 — Itens de ação (15 min)
- Cada item deve ter: descrição, um responsável (não "a equipa"), data de entrega
- Almeje 2 a 3 itens no máximo; mais do que isso dilui a responsabilização
- Avance quaisquer itens incompletos da Secção 1
Encerramento (5 min)
- Avaliação rápida +/-/delta da própria retro
- Confirme que o recap é enviado antes do fim do dia
O que os formatos populares de retro ignoram
Start/Stop/Continue e O que Correu Bem/O que Melhorar/Itens de Ação são ambos formatos válidos. O problema não é o formato — é que os modelos raramente codificam o passo de revisão no início. Esse passo é a única coisa que cria continuidade de responsabilização de uma retro para a seguinte. Sem ele, a retro é uma máquina de sentimentos, não uma máquina de mudança.
Os modelos também não tratam a disciplina do limite de tempo. "O que melhorar" ultrapassa quase universalmente porque é emocionalmente mais envolvente do que "o que correu bem". Sem limites rígidos, uma retro de 60 minutos torna-se 90 minutos de discussão e 5 minutos de itens de ação apressados no final. Os itens de ação são a única parte que muda alguma coisa.
A terceira lacuna: os itens de ação são escritos como diretivas vagas. "Melhorar a comunicação frontend-backend" não é um item de ação. "A Sara vai agendar uma sincronização semanal de 30 minutos entre os leads de frontend e backend, a começar na próxima segunda-feira" é. O responsável e a data de início têm de ser nomeados na sala — mais tarde, os pormenores suavizam-se.
O custo acumulado destes padrões surge semanas depois como contexto que nunca foi capturado e decisões que são relitígadas. O imposto das reuniões aborda como isto se parece quantitativamente ao longo de um trimestre.
Por que os recaps de retro são mais difíceis de escrever do que as notas de standup
Os recaps de standup são curtos. Os recaps de planeamento de sprint são estruturados. Os recaps de retrospetiva são difíceis porque o conteúdo é desordenado — post-its, discussão que salta entre secções, uma mistura de sentimento e dados. Quem escreve o recap tem de reconstruir um fio coerente a partir de uma reunião que se moveu em múltiplas direções ao mesmo tempo.
O Pavleur trata bem desta complexidade precisamente por causa dessa desordem. Captura tudo o que foi dito durante a reunião e o que quer que estivesse no ecrã — o quadro partilhado, o gráfico de velocidade da Secção 2, o ticket de incidente referenciado na Secção 4. O relatório pós-reunião é estruturado, com itens de ação extraídos do que foi efetivamente decidido na sala (com responsáveis e datas, conforme nomeados). Sem necessidade de reconstrução, sem limpeza após a chamada.
As ferramentas de transcrição apenas de áudio capturam as palavras mas não o contexto visual. Numa retro, o visual é muitas vezes a parte mais importante — o quadro de post-its, o gráfico que revelou um padrão, o ticket que ancorou uma discussão. Esse contexto não existe num recap apenas de áudio. Para uma comparação direta de ferramentas: Pavleur vs. alternativas.
Modos de falha comuns na retro
O mesmo item de ação aparece em três retros consecutivas. A Secção 1 não é negociável. Se um item continua por fazer, ou abandone-o com um motivo declarado ou escale-o — não o avance indefinidamente.
A discussão transforma-se em desabafo sem resolução. O papel do facilitador na Secção 4 é traduzir "esse processo está partido" numa coisa específica e modificável. Se não consegue torná-la específica em 30 segundos, vai para o parking lot.
Ninguém adiciona itens de forma assíncrona antes da reunião. Envie o quadro 24 horas antes. Coloque 2 a 3 itens para quebrar o problema da tela em branco. As reuniões correm melhor quando todos chegam com algo escrito.