Retrospectivas de equipe

Nível: B2

Objetivo

Conduzir e participar de retrospectivas (retros) de equipe em inglês: estruturar o que deu certo, o que não deu, registrar lições aprendidas, propor experimentos e definir ownership para que a discussão seja produtiva, segura e orientada a ação.

Explicação

A *retrospective* (ou *retro*) é uma reunião curta e estruturada em que a equipe olha para trás, normalmente ao fim de um sprint ou de uma iteração. Em B2, espera-se que você não só participe, mas também facilite a conversa: organize as falas, mantenha o foco e transforme observações em ações concretas.

A estrutura padrão: went well / didn't go well / lessons learned

Três colunas ou seções cobrem a maior parte das retros. A primeira celebra o que funcionou; a segunda expõe o que atrapalhou; a terceira extrai aprendizados reutilizáveis:

• `What went well this sprint?`
• `What didn't go well this sprint?`
• `What did we learn that we can carry forward?`

Essas três perguntas aparecem em ferramentas como Jira, Linear e Mural. Use o tempo verbal consistente: `We shipped the new dashboard on time.`, `Pair programming reduced review time.`, `Our alerting was too noisy.`

Lessons learned vs action items vs experiments

Em B2, é importante distinguir três saídas diferentes de uma retro:

• Lesson learned (lição aprendida): uma observação geral que a equipe leva para o futuro, sem prazo nem dono — `Code reviews need a checklist for database changes.`
• Action item (item de ação): uma tarefa com dono e prazo — `Anna will draft the checklist by Friday.`
• Experiment (experimento): uma mudança pequena e reversível a ser testada por um ciclo — `We will try a 15-minute standup for two sprints.`

Misturar essas três categorias é o erro mais comum em retro: uma boa lesson vira um action sem dono, ou um action vira uma lesson vaga. Durante a discussão, force a pergunta: "Is this a lesson, an action, or an experiment?"

Ownership, blockers e follow-up

Toda ação precisa de um dono claro (*ownership*). Em vez de "someone should…", use um nome próprio ou um papel específico: `Marco owns the migration script.`, `The on-call lead owns the postmortem.` Sem dono, o item morre.

Se algo continua travado de uma retro para outra, chame de *blocker* e registre na coluna de "didn't go well" da próxima retro. O *follow-up* (retorno) é a parte em que a equipe reabre os itens da retro anterior — a regra prática é revisar os action items da retro passada antes de abrir a nova.

Facilitating productive discussion

Em B2, espera-se que você conduza a conversa, não só responda. Frases úteis para o facilitador:

• Abrir: `Let's start with what went well.`, `We'll timebox this to 45 minutes.`, `If a topic is off-track, we'll put it in the parking lot.`
• Aprofundar: `Can you say more about that?`, `What was the impact?`, `Is this a lesson, an action, or an experiment?`
• Redistribuir a fala: `Has anyone else seen this?`, `Let's hear from someone who hasn't spoken yet.`
• Fechar: `To summarize: Anna owns X, Marco owns Y, and we'll revisit this next sprint.`

Um *parking lot* (estacionamento) é uma lista separada para ideias boas mas fora do escopo da retro atual. Use `Let's put that in the parking lot and come back to it later.` quando o time começa a derivar.

Tom e registro

Retros pedem um registro profissional, mas não rígido. Misture marcadores como *moreover*, *however*, *on the other hand* e *from a practical standpoint* para articular nuances sem soar como lista solta. Evite culpabilizar pessoas — prefira frases como `We didn't catch this in review` em vez de `You missed this in review`. O objetivo é melhorar o sistema, não apontar dedos.

Exemplos

Erros comuns

• Misturar lesson learned com action item: 'We learned to write better tests' é vago sem dono; transforme em 'Anna will write a test-writing checklist by Friday.'
• Dizer 'someone should…' em vez de atribuir ownership: a frase sem dono morre; use sempre um nome próprio ou papel específico.
• Usar 'what doesn't go well' em vez de 'what didn't go well': a retro olha para o passado recente, portanto o verbo fica no passado.
• Culpabilizar pessoas: 'You missed this in review' deve ser reescrito como 'We didn't catch this in review', focando no sistema.
• Pular o follow-up dos action items da retro anterior: a próxima retro deve começar revisando o que ficou pendente.
• Permitir que um único tópico domine 30 minutos da retro: use 'Let's put that in the parking lot' quando o assunto não cabe no tempo.
• Listar elogios vazios: 'good job everyone' não é um item útil; cite uma ação específica que deu certo.

Prática guiada

Reescreva cada frase abaixo no estilo de uma retro, atribuindo ownership e classificando o tipo de saída:

• Vago: 'Someone should fix the alerting.'

Como action item: 'Marco owns the alerting cleanup. He will reduce noise by next sprint.'

• Elogio vago: 'The team did a great job.'

Como 'went well': 'Pair programming cut review time by almost half.'

• Observação sem tipo: 'Our deploys are risky.'

Como lesson learned: 'Deploys need a checklist and a rollback plan before going to production.' Como experiment: 'We will try a four-eyes review on production deploys for two sprints.'

Repare como o mesmo problema pode virar uma lesson (geral) ou um experiment (testável) dependendo do tipo de saída que a equipe quer.

Resumo

Uma retrospective tem três colunas padrão: what went well, what didn't go well e lessons learned. Cada saída vira uma lesson (geral, sem dono), um action item (com dono e prazo) ou um experiment (mudança pequena, reversível, com ciclo de teste). Ownership sempre com nome próprio ou papel; sem dono, nada acontece. O facilitador timebox'a a discussão, usa o parking lot para desviar tópicos fora do escopo, distingue os três tipos de saída e fecha a retro resumindo donos e prazos. Tom profissional, sem culpabilizar pessoas: 'We didn't…' em vez de 'You didn't…'.

História: Retrospectivas de equipe

Nível: B2

História em inglês

Setting up the retro

On Friday afternoon, the payments team gathered for their end-of-sprint retrospective. Anna, the facilitator, opened the meeting: "Let's timebox today's retro to forty-five minutes and start with what went well." She then reminded the team to follow up on last sprint's action items before opening the new column. Two items from the previous sprint were still open: a database review checklist and a dashboard follow-up. Marco said, "I'll own the dashboard follow-up. The checklist is partly done, but Anna, can you finish it?"

What went well and what didn't

The team moved on to the first column. Several people shared what went well. Kudos to Marco for handling last weekend's outage calmly and writing a clear postmortem. Pair programming on the new payment flow also cut review time by almost half. Then Anna opened the second column: "What didn't go well this sprint?" One engineer raised a blocker: the staging environment had been flaky for two weeks, which delayed several test runs. Another teammate added that the alerting was still too noisy, so the on-call rotation kept ignoring pages.

Lessons, experiments, and follow-up

After twenty minutes, Anna summarized the discussion: "So we have one lesson, one experiment, and one open action item." The lesson: production deploys always need a rollback plan before going live. The experiment: the team will try a four-eyes review on production deploys for the next two sprints. The open action item: Marco will set up a weekly staging health check and report back next sprint. Before closing, Anna asked the team, "Has anyone else seen this, or is it safe to put it in the parking lot?" No one else spoke up, so the team agreed to revisit the noisy alerting topic in the next retro.

Tradução linha por linha

Notas de vocabulário

• retrospective = reunião de fim de sprint em que a equipe revisa o que deu certo, o que não deu e o que aprendeu; forma abreviada: retro.
• timebox = limitar o tempo de uma atividade; aqui, a retro de 45 minutos para evitar que um único tópico domine a reunião.
• what went well = cabeçalho da coluna positiva; verbo no passado porque a retro olha para o sprint que acabou.
• kudos = elogio informal ou formal; quase sempre sem 's' final visível em inglês, mas combinado com 'kudos to + pessoa'.
• pair programming = duas pessoas programando juntas no mesmo código; aqui, reduziu o tempo de revisão em quase metade.
• blocker = impedimento que trava o trabalho; no texto, o ambiente de staging instável atrasou várias execuções de teste.
• action item = tarefa com dono e prazo; aqui, Marco é dono do follow-up do dashboard até a próxima sprint.
• lesson learned = observação geral sobre o futuro, sem dono nem prazo; aqui, deploys em produção precisam de um plano de rollback.
• experiment = mudança pequena, reversível e com ciclo de teste; aqui, revisão a quatro olhos em deploys de produção por duas sprints.
• parking lot = lista de tópicos adiados para tratar depois; no fim, os alertas barulhentos foram para o parking lot até a próxima retro.

Perguntas de compreensão

1. Who facilitated the retro, and how long was the retro timeboxed?
2. What two items from the previous sprint were still open?
3. Who took ownership of the dashboard follow-up?
4. What went well in this sprint, according to the team?
5. Which blocker did the team raise in the 'didn't go well' column?
6. What was the lesson learned from this retro?
7. Which experiment did the team agree to try, and for how long?
8. What did the team decide to do with the noisy alerting topic at the end of the retro?

Prática com a história

1. Classifique: 'Anna will finish the database review checklist by Friday.'
2. Classifique: 'We will try a four-eyes review on production deploys for the next two sprints.'
3. Reescreva atribuindo ownership: 'We need to write a better alerting policy.'
4. Traduza: 'Vamos colocar esse tópico no parking lot e voltar a ele na próxima sprint.'
5. Complete: 'Before we start, let's ___ up on last sprint's action items.'