Sprint retrospective e sprint review: significado, processo e principais diferenças
Resposta rápida
Você provavelmente já conhece a retrospective como uma das cerimônias do framework Scrum. Pense nela como um espaço onde a equipe reflete sobre como está trabalhando em conjunto. Não se trata de descobrir quem é responsável pelo quê; é o momento de focar exclusivamente no que pode ser melhorado.
A review tem um propósito diferente. Ela não é centrada no crescimento da equipe, mas no incremento do produto.
Ambas as práticas são uma boa forma de as equipes Agile melhorarem continuamente seus processos. Elas ajudam a garantir que todos entrem no próximo sprint trabalhando de forma mais eficiente.
O que é uma sprint retrospective
Essa cerimônia ágil ocorre toda vez que um sprint termina e serve para que a equipe determine o que conseguiu realizar. Seu principal objetivo é garantir que o próximo sprint seja melhor, mais tranquilo e sem eventos inesperados.
Ao contrário do que você pode pensar, essa reunião não serve para apontar culpados. Na verdade, é bem o oposto, já que apontar culpados não trará nenhum benefício para o projeto ou para a equipe. O objetivo é alcançar a melhoria contínua.
Realizar retrospectives de forma consistente é o que as torna eficazes. Uma ferramenta de gestão de projetos como o Flowlu pode ajudá-lo a manter tudo em um só lugar — desde o acompanhamento de prioridades até o gerenciamento do seu próximo sprint. Ele também possui um criador de templates de retrospective onde você pode experimentar um template pronto para conduzir uma reunião bem-sucedida.
Os participantes
#1: Scrum master
É a pessoa responsável pela reunião e por mantê-la focada na melhoria. Em muitas equipes, esse papel também é chamado de facilitador.
#2: Os desenvolvedores
Estes são os principais participantes. São eles que precisarão compartilhar suas experiências tanto sobre o que os ajudou a ter sucesso quanto sobre o que os impediu.
#3: O product owner
É a pessoa responsável por relatar como foi a colaboração e por esclarecer os requisitos.
O resultado esperado
Uma reunião de retrospective tem um objetivo: quando ela termina, você sai com uma lista de itens de ação que precisam ser melhorados na próxima iteração. A última coisa que todos querem é que essa lista seja vaga. O resultado sempre precisa ser acionável.
Por exemplo, em vez de algo como "Conversar mais sobre design," deve dizer algo mais próximo de "O product owner precisa adicionar um link para todos os materiais antes da fase de planejamento." (Responsável: Peter).
Sprint review vs retrospective
Aqui está uma comparação rápida:
|
Review |
Retrospective |
|
| Propósito |
Focada no "Quê". Verifica o entregável e coleta feedback das partes interessadas. |
Centrada no "Como". Analisa como foi a iteração em termos de ferramentas, processos, relacionamentos e pessoas, e elabora um plano de melhoria contínua. |
| Público |
Além do scrum master, dos desenvolvedores e do product owner, os participantes também incluem a gestão, clientes, partes interessadas e usuários. |
Apenas os membros principais participam dessa cerimônia. |
| Agenda |
O product owner começa revisando o que foi feito, enquanto os desenvolvedores demonstram o produto funcional. As partes interessadas são convidadas a dar feedback, que o product owner leva em conta para o próximo ciclo. |
Todos se reúnem e cada membro é questionado sobre o que foi bem e o que não foi. Isso fornece ao grupo material para debater e decidir melhorias para o próximo ciclo. |
| Artefatos |
Product backlog → product owner. Sprint backlog → desenvolvedores. Incremento → equipe Scrum. |
Uma lista de novas prioridades para iniciar o próximo ciclo. |
| Resultados |
Um novo conjunto de prioridades para o próximo ciclo, tornando-o mais rápido e tranquilo. |
Uma lista de novos itens acionáveis para iniciar o próximo ciclo. |
| Exemplos |
Desenvolvimento de uma funcionalidade de checkout para convidados. Durante o processo de sprint review, os desenvolvedores mostram a tela e uma demo. Uma parte interessada então afirma que precisa de uma caixa de seleção de opt-in para newsletter antes que o usuário efetue o pagamento. Antes do término da reunião, o product owner escreve uma nova user story e a adiciona como prioridade ao backlog. |
A reunião acontece mais tarde naquela tarde. Um desenvolvedor menciona que, embora a demo tenha corrido bem, um problema com a documentação da API custou ao grupo dois dias extras. Outro desenvolvedor concorda e acrescenta que não pôde ajudar na ocasião porque estava ocupado em outra tarefa. Todos então trabalham juntos em um novo plano de ação com base nessas descobertas. |
Como conduzir uma reunião de retrospective eficaz
Passo #1: Estabeleça o contexto
Pense neste passo como um aquecimento — um quebra-gelo antes da reunião em si. De 5 a 10 minutos geralmente é suficiente para avaliar o nível de energia de todos os participantes. Você pode perguntar diretamente ou usar uma enquete anônima. Alguns também utilizam jogos divertidos de retrospective.
Passo #2: Colete feedback
Idealmente, este passo leva entre 10 e 15 minutes. Use-o para coletar feedback de todos. Ainda não deve haver nenhuma análise.
Você pode usar post-its se preferir algo físico, ou um quadro branco digital como o Miro. Certifique-se de que todos usem o mesmo formato para compartilhar seu feedback como parte da agenda da reunião.
Por exemplo, os 4 Ls ("gostei," "aprendi," "faltou," e "desejei") ou o clássico "o que foi bem" e "o que foi mal".
Passo #3: Agrupe os insights
É quando você começa a identificar padrões. Este passo deve levar cerca de 15 a 20 minutos. O objetivo é identificar tendências em todos os post-its coletados. Agrupe ideias semelhantes e deixe os participantes votar para destacar as 3 a 5 mais urgentes.
Passo #4: Defina as ações
É aqui que acontece o brainstorming. Tenha em mente que você precisa sair com uma lista de itens acionáveis. Não anotações genéricas, mas soluções específicas para os problemas discutidos.
Passo #5: Atribua responsáveis
O objetivo aqui é responsabilizar alguém para que nada se perca. 5 minutos devem ser mais do que suficientes para encontrar um voluntário para cada item.
Lembre a todos que a pessoa responsável não precisa fazer todo o trabalho — ela é responsável por garantir que o item não seja esquecido. Seu papel é acompanhá-lo, impulsioná-lo e reportar na próxima retrospective.
Encerre a reunião com uma lista escrita de todas as ações e adicione-as à sua ferramenta de gestão de projetos.
Perguntas, erros e templates
Exemplos de perguntas para sprint retrospective
Algumas equipes simplesmente não respondem bem a perguntas como "O que foi bem?"
Então, se seus colegas são assim, há outras formas de iniciar uma reunião de retrospective.
Tente fazer outros tipos de perguntas.
-
Se você quer quebrar o gelo
Comece com algo como "Você viu alguém conquistar algo esta semana? O que foi?"
-
Se você precisa desbloquear questões relacionadas a processos
Você pode perguntar: "Você pode me dizer qual foi a tarefa mais repetitiva que teve de fazer neste sprint?"
-
Se você quer descobrir riscos que pode enfrentar no futuro
Perguntas como "Você tomou um atalho neste sprint que precisará corrigir depois?" podem ser uma boa ideia.
Erros comuns
#1: Nenhuma ação real
O principal objetivo das reuniões de retrospective é reunir conhecimento suficiente para elaborar uma lista clara de melhorias. Portanto, não passe a reunião inteira focado no problema; a grande maioria do tempo deve ser dedicada a buscar e analisar soluções.
#2: Apontar culpados
Como mencionamos anteriormente, essas reuniões têm como objetivo ajudar as equipes a continuar melhorando a saúde do time. Elas não servem para rastrear quem fez o quê, quando ou quanto tempo levou. Portanto, reformule as perguntas para apontar para problemas e não para indivíduos.
#3: Itens de ação em excesso
Embora o objetivo seja claramente a melhoria contínua, você não quer encerrar a reunião com uma lista de 10 ou 20 itens. Certifique-se de sair com no máximo 3 itens de acompanhamento.
#4: Não utilizar os itens de ação
Para garantir que não sejam esquecidos, integre essas melhorias ao seu fluxo de trabalho imediatamente.
Seu checklist de acompanhamento
A coisa mais importante a fazer após uma scrum retrospective é adicionar suas novas prioridades ao seu software de gestão de projetos, para que não sejam esquecidas.
Siga o checklist abaixo:
#1: Antes de começar
- Confirme se as prioridades da reunião anterior foram concluídas e se resolveram o problema.
- Use métricas como defeitos escapados, gráficos de burndown e velocidade para determinar o que aconteceu.
- Tenha o quadro pronto para uso (físico ou digital).
#2: Durante a reunião
- Mantenha todas as discussões construtivas.
- Atribua a cada item acionável um responsável e uma data de entrega.
#3: Após o encerramento
- Adicione os itens de ação ao Flowlu (ou à ferramenta de gestão de projetos de sua preferência).
- Revise os itens de ação em cada daily standup.
O Flowlu é uma das opções mais completas para isso. Ele possui um ambiente Agile desenvolvido especificamente para que você possa iniciar sprints, agendar retrospectives recorrentes e gerenciar tudo em um só lugar. Após a reunião, adicione os próximos passos, classifique cada um por tipo — tarefa, bug ou história — defina uma prioridade e torne-os visíveis para toda a equipe. Se o trabalho abrange mais de um sprint, agrupe-o em um epic e vincule os issues individuais a ele conforme avança.
À medida que o sprint avança, o Flowlu gera automaticamente um gráfico de burndown. Isso oferece uma visão rápida e clara de se a equipe está no caminho certo para concluir o objetivo do sprint dentro do prazo estabelecido.
Execute sprints de forma eficaz
Embora uma scrum retrospective seja muito importante, você não pode tratá-la como apenas uma lista de ideias anotadas e deixadas para serem esquecidas. O objetivo é pegar o que aconteceu no sprint anterior e usá-lo para melhorar o próximo. Se você não executar, estará simplesmente desperdiçando tempo.
Uma das coisas mais importantes a lembrar sobre essas reuniões é que elas têm tempo limitado. Não transforme algo que pode ser feito em uma hora em uma reunião de 3 ou 4 horas. Isso não será nada produtivo.
É uma cerimônia ágil no Scrum. Seu principal objetivo é entender o que a equipe fez bem e o que errou para melhorar no próximo sprint.
É conduzida pelo scrum master e os outros participantes incluem os desenvolvedores e o product owner.
Embora existam diferentes abordagens dependendo da sua equipe, as perguntas mais comuns que os colaboradores precisarão responder incluem:
- O que foi bem?
- O que foi mal?
- O que podemos fazer no futuro?
Na maioria dos casos (para uma iteração de 2 semanas), essas reuniões duram cerca de 1,5 hora. No entanto, o tempo depende do número de dias do sprint.
Por exemplo, se o sprint durou 3 semanas, a reunião pode durar até 2,25 horas. Caso o sprint tenha durado apenas 1 semana, a retrospective deve levar no máximo 45 minutos.
