Da retro à ação: como fazer os combinados acontecerem

O que são as ações da retrospectiva (e por que elas quase nunca acontecem)

As ações da retrospectiva — também chamadas de combinados, action items ou plano de ação da retro — são as mudanças concretas que o time decide fazer depois de discutir o que funcionou e o que travou no último ciclo de trabalho. Elas são o produto final da retrospectiva de sprint: a conversa existe para gerar aprendizado, mas o aprendizado só vale alguma coisa quando vira comportamento novo na semana seguinte.

O problema clássico todo gestor conhece: a retro foi ótima, o time desabafou, os post-its encheram o quadro, todo mundo saiu da sala se sentindo ouvido — e a semana seguinte foi exatamente igual à anterior. Na retro seguinte, os mesmos problemas voltam, agora com um tom de cansaço: "a gente já falou disso". Depois de três ou quatro rodadas assim, o time para de levar a cerimônia a sério, porque aprendeu que falar não muda nada. A retro morre não por falta de conversa, mas por falta de consequência.

A boa notícia é que a solução não exige ferramenta sofisticada nem facilitador profissional. Ela cabe em cinco práticas simples: escolher poucas ações, dar dono e prazo a cada uma, colocar a ação no board junto com o trabalho normal, revisar os combinados na abertura da retro seguinte e, quando uma ação prova seu valor, promovê-la a política do time. Este artigo percorre cada uma delas.

Escolha poucas ações: uma a três, nunca dez

A primeira armadilha é a empolgação. A retro rendeu, apareceram doze problemas, e o time — com a melhor das intenções — cria doze ações. Resultado previsível: nenhuma acontece. Ação de retro compete com o trabalho do dia a dia, com as entregas, com as urgências. Se o time mal dá conta do backlog, não vai dar conta de doze mudanças de processo ao mesmo tempo.

A regra prática é sair da retro com uma a três ações, e está tudo bem se for só uma. O critério de escolha não é "o que é mais fácil", e sim "o que mais doeu nesta sprint". Uma forma simples de decidir é a votação com pontos: cada pessoa recebe três votos e distribui nos problemas que mais quer ver resolvidos. Os dois ou três mais votados viram ação; o resto fica registrado e pode voltar na próxima rodada — se ainda for relevante, o que muitas vezes não é.

Dois exemplos de como isso funciona fora do papel:

• O time de marketing da Renata levantou oito incômodos na retro, de "briefing chega incompleto" a "muita reunião". Em vez de atacar tudo, votaram e escolheram um só: criar um checklist de briefing obrigatório antes de qualquer peça entrar em produção. Uma ação, bem feita, eliminou a fonte de metade das outras reclamações.
• O time de atendimento do Jorge vivia reclamando de retrabalho nos chamados escalados. A ação escolhida foi mínima: durante duas semanas, registrar em uma planilha o motivo de cada escalação devolvida. Não resolvia o problema — mas dava o dado para resolver na retro seguinte. Ação pequena e investigativa também é ação.

Se o seu time usa formatos como o Start, Stop, Continue, a priorização fica ainda mais natural: os itens de "start" e "stop" mais votados já são candidatos diretos a virar combinado.

Toda ação precisa de dono, prazo e verbo

Uma ação sem dono é um desejo coletivo. "Melhorar a comunicação com o time de vendas" não é uma ação — é um tema. Ninguém sabe o que fazer na segunda-feira de manhã com essa frase. Para um combinado ter chance real de acontecer, ele precisa de três ingredientes:

1. Um verbo concreto e um resultado observável. Em vez de "melhorar a comunicação com vendas", escreva "criar um resumo semanal de lançamentos e enviar toda sexta para a lista de vendas". Qualquer pessoa consegue responder sim ou não à pergunta "isso foi feito?".
2. Um dono com nome. Uma pessoa, não "o time". O dono não é quem executa tudo sozinho: é quem responde pela ação, puxa quem precisar e traz o status na retro seguinte. Quando o dono é todo mundo, na prática é ninguém — e a ação morre no limbo da responsabilidade difusa.
3. Um prazo dentro do próximo ciclo. Se a ação não cabe em uma sprint ou em duas semanas, ela está grande demais: quebre em um primeiro passo que caiba. "Reestruturar o processo de onboarding" vira "esboçar o novo roteiro da primeira semana e apresentar na próxima retro".

Um teste rápido antes de encerrar a cerimônia: leia cada ação em voz alta e pergunte "quem, faz o quê, até quando?". Se alguma das três respostas ficar no ar, a ação ainda não está pronta. Esse minuto de rigor no final da retro economiza semanas de frustração — e é um dos antídotos mais eficazes contra os erros mais comuns na retrospectiva.

Vale registrar também o porquê em uma linha: "criamos o checklist de briefing porque 4 das 6 peças da sprint voltaram por falta de informação". Quando alguém questionar o combinado dali a dois meses — e alguém vai questionar —, o contexto está escrito.

Leve a ação para o board: combinado invisível não sobrevive

Aqui está o passo que a maioria dos times pula, e é justamente o que separa retro decorativa de retro que muda a realidade: a ação da retro precisa entrar no mesmo fluxo de trabalho de todo o resto. Se as entregas do time vivem em um board e os combinados da retro vivem em uma foto do quadro perdida no chat, o resultado está decidido antes de começar: o que está no board acontece, o que está na foto não.

A lógica é a mesma da hierarquia Feature → User Story → Task: trabalho que importa vira item rastreável, com título claro, responsável e coluna de status. Uma ação de retro é trabalho que importa. Então ela vira um item como qualquer outro — na maioria dos casos uma task ou uma user story pequena, dependendo do tamanho. "Criar checklist de briefing" é uma task do dono da ação. "Redesenhar o roteiro de passagem de plantão da equipe de enfermagem" pode ser uma story com duas ou três tasks dentro.

Colocar a ação no board traz três efeitos imediatos:

• Visibilidade diária. O combinado aparece na daily, no planejamento, na revisão de andamento — em vez de reaparecer só na retro seguinte, tarde demais.
• Concorrência honesta por capacidade. Se a sprint está lotada, o time decide conscientemente o que sai para a ação entrar, em vez de fingir que ela acontecerá "nas horas vagas" que não existem.
• Status sem cobrança constrangedora. Ninguém precisa perguntar "e aquele combinado?" no tom de quem cobra dívida; basta olhar a coluna em que o item está.

No TeamBOX, esse caminho é curto de propósito: o post-it da retro vira item no board da sprint, com dono e discussão no próprio card — o combinado sai da cerimônia já dentro do fluxo, sem depender da memória de ninguém.

Um exemplo fora da TI: o time de RH da Camila decidiu na retro que toda vaga aberta teria uma conversa de alinhamento com o gestor requisitante antes da divulgação. A ação virou um item no quadro do time ("redigir roteiro da conversa de alinhamento — dona: Paula — até dia 20") e, depois, uma etapa fixa do processo seletivo. Sem o item no quadro, teria sido só mais uma boa intenção.

Abra a retro seguinte revisando os combinados

Se existe um único hábito capaz de transformar a relação do time com a retrospectiva, é este: os primeiros cinco minutos de toda retro são dedicados a revisar as ações da retro anterior. Antes de qualquer dinâmica nova, antes dos post-its, o facilitador projeta os combinados e pergunta, um a um: feito, em andamento ou abandonado?

Essa revisão faz três coisas ao mesmo tempo:

• Cria consequência. O time aprende que combinado assumido é combinado revisitado. Isso muda a qualidade das ações propostas: ninguém mais sugere ação vaga sabendo que vai prestar contas dela em duas semanas.
• Celebra progresso. Quando a ação foi feita e funcionou, o time começa a retro com uma vitória concreta — o que alimenta a confiança de que a cerimônia vale o tempo dela. É o mesmo princípio de mostrar valor entregue que faz uma boa sprint review funcionar.
• Expõe padrões. Se a mesma ação aparece "em andamento" pela terceira retro seguida, o problema não é disciplina: a ação está grande demais, ou o dono está sobrecarregado, ou o time não quer aquela mudança de verdade. Cada um desses diagnósticos pede uma resposta diferente, e a revisão é o que os torna visíveis.

Importante: abandonar uma ação não é fracasso, desde que seja uma decisão explícita. "Decidimos não seguir com o rodízio de facilitação porque o time preferiu fixar a Marina" é um desfecho legítimo. O que corrói a confiança não é abandonar — é deixar morrer em silêncio.

Para quem facilita, uma dica prática: mantenha a lista de combinados no mesmo lugar sempre (o board resolve isso sozinho) e resista à tentação de pular a revisão "porque hoje temos muito assunto". O dia em que a revisão é pulada é o dia em que o time entende que ela era opcional. Boas perguntas para a retrospectiva ajudam muito na conversa — mas nenhuma pergunta substitui a prestação de contas do início.

Quando a ação vira política do time

Algumas ações têm prazo de validade natural: são experimentos. "Vamos testar daily às 9h30 em vez de 9h por duas semanas" termina com um veredito — deu certo ou não. Outras ações, quando dão certo, pedem promoção: deixam de ser combinado temporário e viram política do time — um acordo de trabalho permanente, escrito, que vale por padrão.

O sinal de que chegou a hora é simples: o time revisou a ação em duas ou três retros seguidas e a resposta foi sempre "sim, continuamos fazendo, e está funcionando". Nesse ponto, manter o item voltando a cada retro é burocracia. Promova:

1. Escreva a política em uma frase clara no documento de acordos do time (ou na descrição do quadro, ou na pauta fixa da cerimônia): "Toda peça só entra em produção com briefing completo pelo checklist"; "Bug crítico interrompe a sprint e é comunicado no canal do time em até uma hora".
2. Anuncie a promoção na retro, para todo mundo saber que aquilo deixou de ser experimento e virou regra da casa — inclusive quem entrar no time depois, no onboarding.
3. Tire o item do ciclo de revisão. Política não é revisada a cada retro; é revisada quando incomoda. Se daqui a seis meses ela deixar de fazer sentido, alguém traz de volta para a retro e o time decide mudar.

Um exemplo de ponta a ponta: o time de produto do Estevão criou na retro a ação "escrever critérios de aceite antes de qualquer story entrar na sprint". Rodou como combinado por duas sprints, com a analista Bia como dona. Funcionou: o retrabalho caiu visivelmente. Na terceira retro, o time promoveu a ação a política e ela virou parte do "pronto para desenvolver" do quadro. O que nasceu como post-it de desabafo virou norma de qualidade — e ninguém mais precisa lembrar dela, porque o processo lembra sozinho.

Esse é o ciclo completo e saudável: dor discutida na retro → ação pequena com dono e prazo → item no board → revisão na retro seguinte → política do time. Times maduros não são os que têm retros mais animadas; são os que têm esse ciclo girando há tempo suficiente para o processo de trabalho ser, em grande parte, feito de aprendizados promovidos.

Checklist: sua retro está gerando realidade?

Antes de encerrar a próxima retrospectiva, passe por esta lista com o time:

• Saímos com no máximo três ações? Se há mais, votem e cortem.
• Cada ação tem verbo concreto, dono com nome e prazo dentro do próximo ciclo? Leia em voz alta e teste: "quem, faz o quê, até quando?".
• Cada ação virou item no board do time? Combinado fora do fluxo de trabalho é combinado perdido.
• A retro de hoje começou revisando os combinados da anterior? Se não começou, este é o primeiro hábito a instalar — antes de qualquer dinâmica nova.
• Alguma ação já provou valor por duas ou três sprints? Promova a política do time e tire do ciclo de revisão.
• Alguma ação está "em andamento" há três retros? Quebre em um passo menor, troque o dono ou abandone explicitamente — qualquer uma dessas é melhor que o limbo.

Se o seu time responde "sim" para as quatro primeiras, a retro deixou de ser um ritual de desabafo e virou o que sempre deveria ser: o motor de melhoria contínua do time — pequeno, constante e visível na semana seguinte.