Eventos do Scrum: quais são e como funcionam na sprint
Os eventos do Scrum são cinco: a Sprint e os quatro eventos que acontecem dentro dela (Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective). Saber os nomes é fácil. O difícil é fazer com que eles funcionem como um sistema, em que a saída de um evento alimenta o próximo, em vez de quatro reuniões avulsas que o time cumpre por obrigação.
O Guia do Scrum 2020 explica para que os eventos existem: cada um é uma oportunidade formal de inspecionar e adaptar os artefatos, e eles foram desenhados para criar regularidade e reduzir a necessidade de reuniões que o Scrum não prevê. Quando os eventos não acontecem ou são feitos de qualquer jeito, o time perde justamente as oportunidades de corrigir o rumo.
Abaixo você encontra o papel de cada evento no ciclo, o que entra e o que sai de cada um, quem participa e um calendário de exemplo para uma Sprint de duas semanas.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
Quais são os eventos do Scrum
| Evento | Pergunta que responde | Duração máxima |
|---|---|---|
| Sprint | Que valor vamos gerar neste ciclo? | Um mês ou menos, duração fixa |
| Sprint Planning | Por que esta Sprint é valiosa, o que entra nela e como vamos fazer? | 8 horas (Sprint de um mês) |
| Daily Scrum | Estamos avançando rumo à Meta da Sprint? O que ajustar hoje? | 15 minutos |
| Sprint Review | O que foi entregue e o que isso muda nos próximos passos? | 4 horas (Sprint de um mês) |
| Sprint Retrospective | Como podemos trabalhar melhor na próxima Sprint? | 3 horas (Sprint de um mês) |
Todos os eventos têm timebox, uma duração máxima. O timebox não é uma meta a ser preenchida: se a Sprint Planning terminou em duas horas com a Meta da Sprint definida e um plano claro, ela terminou.
A Sprint: o evento que contém os outros
A Sprint é o coração do Scrum e o único evento que é, ao mesmo tempo, um ciclo de trabalho. Ela tem duração fixa de um mês ou menos, e uma nova começa logo após o fim da anterior. Todo o trabalho necessário para atingir a Meta do Produto acontece dentro de Sprints, inclusive o refinamento do backlog.
Durante a Sprint:
- nenhuma mudança pode colocar em risco a Meta da Sprint;
- a qualidade não pode cair;
- o Product Backlog é refinado conforme necessário;
- o escopo pode ser esclarecido e renegociado com o Product Owner à medida que o time aprende.
Só o Product Owner pode cancelar uma Sprint, e só quando a Meta da Sprint se torna obsoleta, por exemplo, quando o cliente desiste da funcionalidade ou a regulamentação muda. Detalhes sobre como escolher a duração e o que acontece com o trabalho inacabado estão no artigo sobre o que é Sprint no Scrum.
Como os eventos se encadeiam: entradas e saídas
A melhor forma de entender os eventos do Scrum é olhar o que cada um recebe e o que entrega para o seguinte:
| Evento | Entra | Sai | Participantes |
|---|---|---|---|
| Sprint Planning | Product Backlog ordenado, Meta do Produto, Incremento mais recente, capacidade do time | Meta da Sprint e Sprint Backlog | Scrum Team; outras pessoas podem ser convidadas para dar orientação |
| Daily Scrum | Sprint Backlog e progresso do dia anterior | Plano ajustado para o próximo dia de trabalho | Developers |
| Sprint Review | Incremento, Product Backlog, mudanças no mercado ou no ambiente | Product Backlog revisado | Scrum Team e stakeholders convidados pelo time |
| Sprint Retrospective | Como foi a Sprint: pessoas, interações, processos, ferramentas, Definição de Pronto | Melhorias concretas, que podem entrar no Sprint Backlog da Sprint seguinte | Scrum Team |
Repare na lógica: a Planning transforma o backlog em plano; a Daily mantém o plano vivo; a Review usa o resultado para mudar o backlog; e a Retrospectiva muda o jeito de trabalhar. Se um elo falha, os outros sentem. Uma Review sem stakeholders, por exemplo, devolve à Planning seguinte um backlog que ninguém validou.
Sprint Planning
Começa a Sprint. O Product Owner propõe como o produto pode ganhar mais valor, e o Scrum Team inteiro define a Meta da Sprint. Os Developers selecionam os itens e planejam o trabalho, em geral quebrando itens em tarefas de um dia ou menos. O passo a passo está no artigo sobre como conduzir a Sprint Planning.
Daily Scrum
Evento de 15 minutos dos Developers, todos os dias úteis, no mesmo horário e local. Serve para inspecionar o progresso rumo à Meta da Sprint e ajustar o Sprint Backlog. O formato é livre. Um roteiro completo está em como conduzir a Daily Scrum.
Sprint Review
O penúltimo evento da Sprint. O time apresenta os resultados aos stakeholders e todos discutem o que fazer em seguida. O Guia insiste que é uma sessão de trabalho, não uma apresentação, e que o Scrum Team deve evitar limitá-la a uma demonstração. Veja como prepará-la em como conduzir a Sprint Review.
Sprint Retrospective
Fecha a Sprint. O time examina como foi o trabalho, o que ajudou, o que atrapalhou e como os problemas foram (ou não) resolvidos. As mudanças de maior impacto são tratadas o quanto antes e podem até entrar no Sprint Backlog da próxima Sprint.
Calendário de exemplo: Sprint de duas semanas
O Guia só fixa os limites para a Sprint de um mês e diz que, em Sprints mais curtas, os eventos costumam ser mais curtos. Muitos times usam uma proporção aproximada desses limites. O calendário abaixo é um exemplo ilustrativo de um time que trabalha de segunda a sexta:
| Dia | Evento | Duração no exemplo |
|---|---|---|
| Segunda (semana 1), manhã | Sprint Planning | até 4 horas |
| Todos os dias úteis, 9h30 | Daily Scrum | 15 minutos |
| Quarta (semana 1 e semana 2) | Refinamento do backlog (atividade, não evento) | cerca de 1 hora |
| Sexta (semana 2), manhã | Sprint Review | até 2 horas |
| Sexta (semana 2), tarde | Sprint Retrospective | até 1h30 |
| Segunda seguinte | Nova Sprint Planning | até 4 horas |
Alguns times preferem começar a Sprint na quarta-feira para evitar que feriados de segunda e sexta caiam sempre sobre a Review ou a Planning. O Guia não define o dia de início: o importante é manter a cadência.
Cerimônias, rituais ou eventos?
No mercado, é comum ouvir "cerimônias do Scrum" ou "rituais ágeis". O Guia usa só a palavra eventos, e a diferença não é só de nome. Cerimônia sugere algo formal, repetido por tradição; evento do Scrum é um momento de trabalho com propósito definido. Quando o time passa a tratar a Review como cerimônia, ela vira apresentação de slides. Quando trata como evento, vira uma conversa sobre o que fazer a seguir.
Dois esclarecimentos que costumam aparecer em prova de certificação:
- O refinamento do Product Backlog não é evento. É uma atividade contínua, sem timebox definido pelo Guia.
- Não existe "Sprint 0" nem "Sprint de estabilização" no Guia. Toda Sprint deve produzir pelo menos um Incremento utilizável que atenda à Definição de Pronto.
Como organizar os eventos no seu time
Comece fixando a cadência: duração da Sprint, dia de início e horário da Daily. Depois, garanta que cada evento termine com a sua saída concreta (uma Meta da Sprint escrita, um backlog revisado, uma ou duas melhorias com responsável). O guia completo de métodos ágeis e Scrum mostra como os eventos se encaixam no ciclo ágil como um todo.
Para não perder o que foi decidido na Review e na Retrospectiva, registre as decisões e as ações com responsável e prazo. A ata de reunião com controle de ações da Projeto Diário faz isso em poucos minutos e mostra, na reunião seguinte, quais ações atrasaram, o que dá ao time uma forma simples de conferir se as melhorias combinadas saíram do papel.
