Modelo de retrospectiva: formato, exemplo — e como os action items sobrevivem até a próxima retrospectiva (2026)

Uma retrospectiva é a reunião em que a equipe olha como trabalhou — ao longo de uma sprint, de uma release, de um mês — e decide o que mudar. Não o que construiu; isso é papel da review. O foco é como construiu: o que atrasou o trabalho, o que o fez andar e quais uma ou duas coisas a equipe fará de outro jeito na próxima vez. Um modelo de retrospectiva é a página única que conduz essa conversa em ordem fixa, para que a reunião produza uma decisão e não uma lista de queixas.

Este guia começa pelo ofício — o formato, um modelo de retrospectiva de sprint que você pode copiar, um exemplo preenchido e os quatro conjuntos de perguntas entre os quais a maioria das equipes se alterna. Depois vêm a mecânica: onde a retro vive nas ferramentas que sua equipe já usa e o que acontece com as ações depois da chamada. O verdadeiro teste de uma retrospectiva não é o quadro no fim da hora. São os primeiros cinco minutos da próxima, quando alguém pergunta se as duas mudanças combinadas por todos realmente aconteceram.

O que é uma retrospectiva — e o que ela não é

Quatro reuniões ficam perto da retrospectiva, e as equipes as misturam por sua conta e risco:

A retrospectiva é a única das quatro que trata da própria equipe, na presença da equipe, com a equipe decidindo. Por isso sua saída é pequena — uma equipe consegue mudar um ou dois hábitos por ciclo, não dez — e por isso uma retro com lista longa geralmente virou uma review ou uma revisão de incidente com o nome errado. A pauta da sprint review e a pauta da retro são duas páginas diferentes por um motivo.

Uma retrospectiva também não é uma reunião de status com sentimentos. "Vamos dar uma volta e dizer como foi a sprint" produz um clima, não uma mudança. O modelo abaixo pede dados antes de opiniões, escrita antes de fala e uma decisão antes de a hora acabar.

O que o modelo contém: o formato

Um modelo de retrospectiva utilizável tem sete partes, nesta ordem. A maioria dos modelos que circulam na internet é um subconjunto; as duas partes que mais faltam são a primeira e a última.

1. As ações da retro anterior, conferidas. Antes de qualquer coisa: cada ação da vez anterior, seu responsável e um de três estados — feita, não feita com o motivo, descartada. Dois minutos para uma lista de três. Uma retrospectiva que pula esse espaço está anunciando que suas ações são opcionais, e a sala ouve isso.
2. O período em fatos. O que foi entregue, o que atrasou, o que quebrou, em números ou datas, no quadro antes de qualquer pessoa falar. Três a cinco linhas. Opiniões discutidas sobre os mesmos fatos convergem; opiniões discutidas sobre memórias diferentes, não.
3. O que deu certo. Primeiro por escrito, uma nota por pessoa por ponto, depois lida em voz alta. Escrever primeiro é a regra que deixa a metade quieta da equipe ser ouvida, e o motivo comum de as retros serem dominadas por duas vozes.
4. O que não deu certo. Mesmo método. As notas tratam do trabalho e da forma de trabalhar, não de pessoas; o facilitador move para o parking lot, para uma conversa one-on-one, a nota que cita alguém.
5. Agrupar e escolher. Agrupe as notas e deixe cada pessoa pôr dois votos nos grupos que quer ver tratados. Os um ou dois mais votados são o assunto da retro pelo tempo que resta; o restante espera a próxima, e a lista do que esperou é guardada.
6. Uma ou duas mudanças, como ações. Para cada grupo escolhido, a mudança com a qual a equipe se compromete, escrita como um action item: um responsável, um verbo, uma data. "Melhorar nas estimativas" é um desejo; "Lena — incluir uma checagem de estimativa de 15 minutos no planejamento de quinta — a partir da próxima sprint" é uma ação.
7. Responsáveis, data de verificação e agradecimento. Leia as ações de volta, com os responsáveis; diga a data em que serão verificadas — normalmente a próxima retro; e feche com uma rodada de agradecimentos, nominais. O último item não é enfeite: é o que faz as pessoas aceitarem escrever, da próxima vez, as notas do item 4.

O que fica de fora: tudo o que pertence à review (escopo), à revisão de incidente (a linha do tempo de uma falha) ou a um one-on-one (uma pessoa). Uma retrospectiva que tenta carregar isso se alonga e não decide nada.

Como conduzir uma: antes, durante, depois

Antes: fixe o horário e prepare os fatos. Uma retrospectiva é uma reunião recorrente, depois da review e antes do próximo planejamento, para trabalhar com o que realmente foi entregue; como ela se encaixa na semana está no guia de cadência de reuniões. No dia anterior, o facilitador publica no canal da equipe os fatos do período — a lista do entregue, a do atrasado, os incidentes — e as ações da última retro com seus responsáveis, para que os itens 1 e 2 sejam lidos antes da reunião, e não montados durante ela. Alterne o facilitador: uma retro conduzida sempre pelo gerente vira um relatório para o gerente.

Durante: escrever antes de falar, depois decidir. Abra com a conferência das ações — cada responsável diz se fez ou não, e por quê, em uma frase. Depois os fatos, lidos em voz alta em um minuto. Depois oito minutos de escrita silenciosa sobre o que deu certo e o que não deu, com cada nota visível a todos assim que aparece, no idioma de cada membro se o quadro traduz e no único idioma combinado pela sala se não traduz. Leitura, agrupamento, votos: quinze minutos. Os grupos escolhidos ficam com o resto da hora, e a única tarefa do facilitador nesse trecho é transformar conversa em uma ação com nome antes de o relógio acabar, lendo cada uma em voz alta para que o responsável concorde duas vezes. Cinco minutos no fim: ações com responsáveis e a data de verificação, depois o agradecimento.

Depois: publique a página no mesmo dia, onde a próxima retro vai abri-la. O quadro com suas notas, os grupos escolhidos, as ações com responsáveis e as ações anteriores com seus estados — uma página, para todos, inclusive quem faltou. Depois coloque-a onde a próxima retrospectiva começa: a conferência de ações no topo da próxima página é uma cópia da lista de ações no fim desta. Uma retrospectiva guardada no caderno do facilitador é uma retrospectiva que a equipe não tem.

Como a hora em si é conduzida — a abertura, os blocos de tempo, a releitura dos resultados nos últimos cinco minutos — é o mesmo ofício de qualquer reunião eficaz. O que é específico da retro é a regra de escrever primeiro e o limite de duas mudanças.

Um modelo de retrospectiva de sprint

[Equipe] — Retrospectiva, sprint [número] / [período]
Data: [data] · Horário: [início]–[fim] · Link: [link da reunião]
Objetivo: escolher uma ou duas mudanças na forma como trabalhamos e conferir as que escolhemos da última vez.
Facilitador: [nome, rotativo] · Anotações: [nome ou "o resumo"]
Leitura prévia: a página da última retro, os fatos deste período

1. Ações da última retro — facilitador — 5 min — informação
– [Responsável] — [ação] — prazo era [data] — feita / não feita: [motivo] / descartada
– [Responsável] — [ação] — prazo era [data] — feita / não feita: [motivo] / descartada

2. O período em fatos — facilitador — 3 min — informação
Entregue: [lista]. Atrasou: [lista]. Quebrou: [lista]. [Um número que importa neste período.]

3. O que deu certo — todos, primeiro por escrito — 8 min — discussão
[Notas, um ponto cada, lidas em voz alta depois da escrita.]

4. O que não deu certo — todos, primeiro por escrito — 8 min — discussão
[Notas sobre o trabalho e a forma de trabalhar — não sobre pessoas.]

5. Agrupar e votar — todos — 10 min — decisão
Grupos: [A], [B], [C]. Dois votos cada. Escolhidos: [um ou dois]. Esperam a próxima vez: [o restante].

6. As mudanças com as quais nos comprometemos — equipe — 15 min — decisão
– [Responsável] — [verbo + objeto] — a partir de [data] — verificado na retro de [data]
– [Responsável] — [verbo + objeto] — a partir de [data] — verificado na retro de [data]

7. Responsáveis, data de verificação, agradecimento — 5 min
Ações lidas de volta com os responsáveis. Data de verificação: próxima retro, [data]. Um agradecimento por pessoa, nominal.

Parking lot: [itens levantados e não escolhidos — levados para a página da próxima retro]

O modelo é texto simples: dá para colar em um documento, em um canvas, em uma coluna de post-its de um quadro branco ou em uma mensagem de chat sem reformatar. A ordem é o que importa; a ferramenta, não.

Um exemplo preenchido: uma equipe de produto de oito pessoas, depois de uma sprint de duas semanas

Equipe de plataforma — Retrospectiva, sprint 31
Objetivo: escolher uma ou duas mudanças na forma como trabalhamos e conferir as que escolhemos da última vez.
Facilitador: Mateusz · Anotações: o resumo
Leitura prévia: a página da retro da sprint 30; os fatos da sprint 31 publicados ontem no canal

1. Ações da última retro — 5 min
– Priya — mover a daily para as 09:30 para que Lisboa entre ao vivo — prazo era 2 nov — feita
– Kenji — definição de pronto de uma página para a frente mobile — prazo era 6 nov — não feita: aguardando as edições do líder de QA; nova data 20 nov

2. O período em fatos — 3 min
9 de 11 itens planejados entregues. Atrasaram: o job de exportação, o e-mail de onboarding. Quebrou: um incidente, 40 minutos, o índice de busca. A review de quinta passou 25 minutos do horário.

3. O que deu certo — 8 min
O pareamento na correção da busca a fechou no mesmo dia. O canal guardou os fatos, então ninguém perguntou "o que entregamos" duas vezes. Lisboa entrou em todas as dailies.

4. O que não deu certo — 8 min
Dois itens estavam meio especificados quando a sprint começou. A review estourou o tempo porque a demo estava sendo montada durante a reunião. O relatório do incidente foi escrito com três dias de atraso.

5. Agrupar e votar — 10 min
Grupos: prontidão no início da sprint (6 votos), duração da review (4), relatórios de incidente (3), estimativas (2). Escolhidos: prontidão, a review. Esperam: relatórios de incidente, estimativas.

6. As mudanças com as quais nos comprometemos — 15 min
– Lena — uma checagem de prontidão de cada item na terça antes do planejamento; um item sem especificação de uma linha e sem responsável não entra na sprint — a partir da sprint 32 — verificado na retro de 28 nov
– Tomás — o ambiente de demo pronto e testado até o meio-dia do dia da review — a partir da sprint 32 — verificado na retro de 28 nov

7. Responsáveis, data de verificação, agradecimento — 5 min
Lido de volta. Data de verificação: 28 nov. Agradecimentos à Priya pelo pareamento na busca e a Lisboa pelos começos cedo.

Parking lot: relatórios de incidente; estimativas — primeiros da lista na retro da sprint 32.

Repare no que faz a página funcionar: o primeiro item e o penúltimo são a mesma lista vista com duas semanas de distância. As ações da sprint 31 nasceram no pé da página da sprint 30 e foram julgadas no topo desta; as da sprint 32 serão julgadas em 28 de novembro. Esse ciclo é todo o valor de uma retrospectiva, e é a parte que a maioria dos modelos deixa para a memória.

Quatro conjuntos de perguntas e quando cada um serve

Os itens 3 e 4 do modelo são um par de perguntas, e as equipes se cansam do mesmo par. Quatro alternativas conhecidas, todas ainda terminando nos itens 5 e 6:

Qualquer que seja o conjunto, duas regras valem: escrever antes de falar, e a saída são uma ou duas ações com responsáveis. Um conjunto de perguntas que produz uma parede de notas mais rica, mas nenhuma decisão, tornou a reunião mais interessante e menos útil.

Onde a retrospectiva vive nas ferramentas que você já usa

Cada plataforma importante dá à retro um quadro ou um documento, e cada uma para em um ponto diferente. Apenas comportamento documentado, das páginas dos próprios fornecedores, com o mês em que cada fato foi verificado:

Duas coisas são iguais em todas as linhas. O quadro da retro é um documento ao lado da reunião, no único idioma em que foi escrito ou realizado; e se as ações da última retro foram feitas é uma pergunta que o documento não responde — uma pessoa abre a página anterior na reunião seguinte e a lê para a sala. Onde isso basta, qualquer uma das quatro serve e a tabela é a resposta inteira. Para onde vão depois a transcrição, a gravação e o resumo de uma chamada do Teams ou do Meet, e quem ainda consegue abrir cada um, está mapeado em onde o Teams e o Meet guardam sua transcrição, gravação e resumo; o que a tradução ao vivo de cada plataforma cobre dentro da chamada e onde ela termina está nos guias do Teams e do Meet (Teams, Meet).

Como as ações sobrevivem até a próxima retro

O InterMIND é um espaço de comunicação em que a reunião vive em um canal, então a retrospectiva tem um lar óbvio: um canal só dela, onde os fatos do período e as ações da última retro são publicados no dia anterior, e o canal guarda o resumo de cada sessão, de modo que a página da sprint 30 fica a um clique da da sprint 31. Cada membro escreve no próprio idioma e lê os outros no seu; uma página rascunhada em outro lugar chega ao canal por e-mail — o anfitrião dá ao canal um endereço próprio, e uma mensagem enviada a ele aparece como mensagem comum, com o remetente identificado e os anexos preservados.

Durante a chamada, o quadro é uma nota colocada na tela de todos, ao lado dos blocos de vídeo, com Share to conference: o facilitador a edita ao vivo enquanto a sala escreve seus pontos, e cada participante a lê no próprio idioma, com o original a um toggle de distância. O resumo da sessão anterior pode ser compartilhado na conferência do mesmo jeito, de modo que o item 1 — as ações da última retro — seja o registro de verdade na tela de todos, e não a lembrança de alguém.

Quando a chamada termina, o resumo é escrito a partir da própria reunião: um sumário, os pontos marcados como acordados, em aberto ou em disputa, os action items com responsáveis, cada linha mantendo seu timestamp. Ele chega por e-mail, como mensagem no canal e como link no evento do calendário, e cada membro conectado o lê no próprio idioma — o registro é traduzido por leitor, e não escrito uma vez no idioma que a sala por acaso usou. Qualquer membro pode editá-lo, e cada edição guarda autor e histórico de revisões. O anfitrião pode adicionar uma cópia do resumo a qualquer endereço — a caixa de entrada de um tracker ou de um CRM — para que as duas ações cheguem ao sistema de registro sem que ninguém precise encaminhar nada. O Teams e o Meet, conforme a documentação deles acima, traduzem o momento — legendas na chamada, um resumo no idioma da reunião; aqui, o espaço é o que permanece traduzido.

Em uma organização com as páginas de status de equipe ativadas, as ações da retro também são conferidas. Toda ação que um resumo registra entra na cadeia de tarefas da organização e, quando o próximo resumo é escrito, as abertas são julgadas contra o que foi dito: uma ação que alguém relatou como concluída é marcada como feita; uma ação discutida mas não concluída é marcada como não feita, com o motivo nas palavras da reunião; uma ação que ninguém mencionou continua aberta. Os veredictos ficam na página de status da organização, cada um com o resumo em que se baseia, e no início da próxima sessão a Mia cita os itens abertos e seus responsáveis — assim o item 1 do modelo é falado mesmo quando ninguém abriu a página anterior. As páginas de status de equipe são um recurso em preview: o admin da organização as ativa em Settings → Advanced depois de aceitar os termos alfa (a página Preview features descreve cada um).

Um convidado — um contratado na sprint, um engenheiro de um cliente convidado para uma retro — entra por link, sem conta e sem custo, pelo celular ou no navegador, e ouve a reunião ao vivo no próprio idioma. Depois da reunião, o convidado não fica com registro — a conta é gratuita, e é ela que torna o registro acessível. O anfitrião providencia o espaço e, em um plano pago, paga apenas pelos membros ativos nos 28 dias anteriores; membros que ficam quietos mantêm o acesso sem custo.

• Abra um resumo completo — um registro real, gerado pelo mesmo código que escreve o seu, action items incluídos.
• Experimente a demo ao vivo — sem cadastro; fale e ouça a sala traduzida para cada ouvinte.

A retrospectiva como ofício sobrevive a qualquer ferramenta: alguém ainda precisa perguntar à equipe o que mudar e mantê-la em duas respostas. O que não precisa sobreviver é o segundo trabalho — redigitar o quadro depois da chamada, em um só idioma, e abrir a próxima retro perguntando se alguém fez o que a anterior decidiu.

FAQ

O que é uma reunião de retrospectiva?

Uma retrospectiva é uma reunião recorrente em que uma equipe olha como trabalhou ao longo de um período — uma sprint, uma release, um mês — e se compromete com uma ou duas mudanças na forma de trabalhar. Ela confere primeiro as ações da retro anterior, põe os fatos do período no quadro, coleta por escrito o que deu certo e o que não deu, agrupa e vota, e termina com ações que têm um responsável e uma data de verificação. Ela se distingue da review, que olha o que foi construído, e da revisão de incidente, que olha uma falha.

Como conduzir uma retrospectiva de sprint?

Fixe o horário depois da review e antes do planejamento, e publique no canal da equipe, no dia anterior, os fatos do período e as ações da última retro. Na reunião: confira as ações da vez anterior (cinco minutos), leia os fatos, escreva em silêncio as notas do que deu certo e do que não deu antes de qualquer pessoa falar, leia-as em voz alta, agrupe, vote com dois votos por pessoa e use o tempo restante para transformar os um ou dois grupos mais votados em ações com um responsável e uma data. Leia as ações de volta, diga a data de verificação — normalmente a próxima retro — e feche com agradecimentos. Publique a página no mesmo dia, onde a próxima retro vai abri-la.

Quais são as 5 etapas de uma retrospectiva?

A estrutura de cinco etapas mais usada é: preparar o terreno (objetivo, ações anteriores, regras), coletar dados (os fatos do período e as notas de todos), gerar insights (agrupar as notas e encontrar o padrão por trás delas), decidir o que fazer (uma ou duas ações com responsáveis) e encerrar (releitura, data de verificação, agradecimento). O modelo deste guia corresponde a essas etapas item a item: os itens 1–2 preparam o terreno e coletam fatos, 3–5 coletam e agrupam, 6 decide, 7 encerra.

Qual é a diferença entre uma sprint review e uma retrospectiva de sprint?

A review olha o trabalho — o que foi construído, se é o que se pretendia, o que muda no backlog — com os stakeholders na sala. A retrospectiva olha a forma de trabalhar — o que atrasou a equipe e o que ela vai mudar — só com a equipe. A review deixa itens aceitos e mudanças no backlog; a retrospectiva deixa uma ou duas ações sobre como a equipe trabalha, e as ações da vez anterior marcadas como feitas ou não. A retro fica depois da review para trabalhar com o que realmente foi entregue.

O que é start, stop, continue?

Um conjunto de perguntas de retrospectiva com três colunas: o que a equipe deve começar a fazer, o que deve parar de fazer e o que deve continuar fazendo. Ele substitui o par "deu certo / não deu certo" do modelo básico e serve para equipes que querem ações direto das notas — uma nota de "começar" já é meia ação. O agrupamento, a votação e o limite de uma ou duas mudanças assumidas continuam valendo.

Quais são as 4 perguntas de uma retrospectiva?

Uma retrospectiva clássica faz quatro perguntas: o que fizemos bem, o que aprendemos, o que devemos fazer diferente da próxima vez e o que ainda nos intriga. São os 4Ls em outra forma — liked, learned, lacked, longed for — e funcionam melhor em um período mais longo, como um trimestre ou o fim de um projeto, em que aprender importa tanto quanto corrigir.

Quanto tempo deve durar uma retrospectiva de sprint?

Para uma sprint de duas semanas e uma equipe de cinco a dez pessoas, de 45 a 60 minutos: cinco para as ações anteriores, três para os fatos, dezesseis para a escrita, quinze para leitura, agrupamento e votos, quinze para as mudanças, cinco para fechar. Uma retrospectiva que regularmente passa disso geralmente deixou a review ou uma discussão de incidente entrar na sala; uma retro muito mais curta geralmente pulou a escrita ou as ações.

O que um modelo de retrospectiva deve incluir?

Sete coisas: as ações da retro anterior com seus estados; o período em fatos; o que deu certo; o que não deu — ambos primeiro por escrito; agrupamento e votos; uma ou duas mudanças escritas como action items com responsável e data; e o encerramento — releitura, data de verificação, agradecimento — com um parking lot para o que esperou. As duas partes que a maioria dos modelos pula são a primeira e a penúltima: a conferência das ações antigas e o responsável e a data nas novas. São elas que ligam uma retro à seguinte.

Fontes: Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Recap in Microsoft Teams; Zoom — Generating meeting agenda with AI Companion; Zoom — Using Meeting Summary with AI Companion; Google — Calendar & Meet settings for "Take notes for me"; Google Meet — "Take notes for me" in Google Meet; Slack — Meeting agenda template; Slack — Use huddles in Slack. Cada célula da tabela indica o mês em que seu fato foi verificado: a página de notas da Microsoft, a página de pauta do Zoom, as páginas do Google e as páginas do Slack foram verificadas em outubro de 2026; a página de resumo da Microsoft e a página de resumo de reunião do Zoom, em agosto de 2026. A estrutura de cinco etapas e os conjuntos de perguntas são prática comum e não trazem nenhuma afirmação de fornecedor. Os fornecedores mudam planos, recursos e listas de idiomas com o tempo; consulte as páginas deles para ver o estado atual.