O que foi bem?

Coisas com as quais estamos satisfeitos.

Entregamos todas as histórias comprometidas e batemos a meta da sprint.
Nossas dailies foram eficientes e ajudaram a gente a se manter coordenado.
A nova abordagem de pair programming melhorou a qualidade do código.
O que não foi tão bem?

Coisas que devemos melhorar.

Sofremos com requisitos pouco claros e tivemos que fazer suposições.
Os testes foram feitos às pressas no fim por causa do aumento de escopo no início da sprint.
Falhas de comunicação entre os times de frontend e backend causaram atrasos.
O que queremos testar a seguir?

Coisas que devemos fazer de outro jeito.

Trazer um especialista no assunto para as reuniões de planejamento e refinamento.
Fazer um spike de design para funcionalidades complexas antes da implementação.
Definir um timebox para as tarefas para não ficarmos presos em detalhes.
O que nos intriga?

Perguntas que ainda não têm resposta.

Como podemos melhorar nossas práticas de DevOps e o processo de deploy?
Quais habilidades precisamos desenvolver como time para o próximo projeto?
Vale a pena olhar novos frameworks ou ferramentas de teste?

O que é uma retrospectiva ágil?

Uma retrospectiva ágil faz quatro perguntas simples: o que foi bem, o que não foi tão bem, o que vocês querem testar a seguir e o que ainda intriga vocês. Juntas, elas fazem o time conversar sobre como foi a última sprint e em quais ações focar na próxima. O formato é simples de propósito. Ao conduzi-lo, você mostra ao time que está ouvindo e que pretende agir com base no que ele diz. A prática da retrospectiva é descrita no livro Agile Retrospectives, de Esther Derby e Diana Larsen (com prefácio de Ken Schwaber), e funciona como uma revisão periódica que mantém o time funcionando bem. Feita a cada sprint, a retro revela problemas na forma como vocês desenvolvem e entregam software enquanto eles ainda são pequenos, e dá ao time um momento definido para resolvê-los juntos. Retros curtas e regulares, com ações documentadas, permitem mudar de rumo antes que seja tarde. Conduzir um navio grande funciona do mesmo jeito: pequenas correções ao longo da rota são mais fáceis do que descobrir no fim que você atracou no porto errado. Um post-mortem olha para trás depois que o projeto termina. Uma retrospectiva ágil olha para a próxima sprint, então o tom continua positivo e prático.

Formato de Retrospectiva Ágil

O que foi bem?

Coisas com as quais estamos satisfeitos.

Incentive o time a compartilhar exemplos concretos de sucessos, grandes ou pequenos. Comemore as conquistas do time e as contribuições individuais.

O que não foi tão bem?

Coisas que devemos melhorar.

Crie um ambiente sem culpados para uma discussão aberta e honesta. Foque nos processos, não nas pessoas. Procure as causas-raiz.

O que queremos testar a seguir?

Coisas que devemos fazer de outro jeito.

Incentive o pensamento criativo e esteja aberto a ideias pouco convencionais. Procure experimentos pequenos e práticos para rodar na próxima sprint.

O que nos intriga?

Perguntas que ainda não têm resposta.

Esta é a chance de trazer à tona incertezas ou pontos que precisam de mais investigação. Registre tudo para discutir no futuro.

Quando utilizar esta análise retrospectiva

  • No fim de cada sprint ou iteração, para refletir sobre o ciclo que passou.
  • Quando o time quer identificar pontos específicos para melhorar.
  • Depois de um marco importante do projeto ou de um release, para discutir as lições aprendidas.
  • Sempre que o time se sentir travado e precisar voltar aos trilhos.
  • Durante uma transformação ágil, para tornar a reflexão regular um hábito em todos os times.

Perguntas sugeridas para quebra-gelo

  • Se você pudesse adicionar uma ferramenta ou processo para ajudar o nosso time, qual seria?
  • Qual é uma coisa pequena que poderia ter um grande impacto positivo no nosso time?

Quer um exercício de aquecimento que sua equipe faça, e não apenas responda em voz alta? Veja quebra-gelos gratuitos →

Ideias e dicas para sua reunião de retrospectiva

  • Deixe claro desde o início que não há culpados, para que as pessoas falem abertamente.
  • Defina um timebox para cada seção para manter a retro focada.
  • Ouça todo mundo, não só os mais falantes. Alguns minutos de brainstorming silencioso ajudam.
  • Registre os itens de ação e defina um responsável para acompanhar cada um.
  • Não tente resolver todos os problemas. Escolha os um ou dois principais e rode pequenos experimentos.
  • Reveze o papel de facilitador para ganhar novas perspectivas.

Perguntas frequentes

O que é uma retrospectiva ágil?
Uma retrospectiva ágil é uma reunião no fim da sprint em que o time analisa como foi o trabalho e combina o que mudar. Este modelo usa quatro perguntas: o que foi bem, o que não foi tão bem, o que testar a seguir e o que nos intriga.
Com que frequência fazer uma retrospectiva ágil?
A maioria dos times faz uma no fim de cada sprint. Você também pode fazer uma depois de um release ou marco importante, ou sempre que o time se sentir travado.
Quanto tempo dura uma retrospectiva ágil?
O Guia do Scrum limita a retrospectiva da sprint a três horas para uma sprint de um mês, e sprints mais curtas têm retros mais curtas. Para uma sprint de duas semanas, o comum é 45–90 minutos.
Qual é a diferença entre uma retrospectiva ágil e um post-mortem?
Um post-mortem acontece uma única vez, depois que o projeto termina, e olha para o que deu errado. Uma retrospectiva ágil acontece a cada sprint, para que o time corrija pequenos problemas enquanto ainda há tempo de agir.
Times remotos podem fazer uma retrospectiva ágil?
Sim. No TeamRetro, times distribuídos adicionam ideias, agrupam, votam e definem ações juntos em tempo real, de qualquer lugar.
Pronto para conduzir essa retrospectiva?Experimente esta apresentação ao vivo retrospectiva