Scrum — eventos e timeboxes: Sprint, Planning (8h), Daily (15min), Review (4h), Retro (3h)

A ideia que organiza o assunto

São cinco eventos, e o primeiro contém os outros quatro. A sprint é o contêiner: todo o trabalho necessário para atingir a meta do produto — planning, dailies, review e retrospectiva incluídos — acontece dentro dela. Não existe evento do Scrum entre sprints, e uma sprint começa imediatamente após o término da anterior.

Os eventos existem para criar regularidade e abrir oportunidades formais de inspeção e adaptação. Daí a segunda ideia, que decide sozinha uma boa parte dos itens: cada evento é um timebox. O tempo é a variável travada e o escopo é a variável livre. Quando o trabalho não cabe, o Scrum não estica o prazo — ele renegocia o conteúdo com o Product Owner.

Com isso, quase todo item do assunto se resolve com três perguntas: qual evento é esse, qual é o propósito declarado dele, e quanto tempo ele tem. Se o item trocar o propósito de um evento pelo do vizinho, ou mexer no número, está errado.

Os três artefatos e os compromissos que eles carregam — meta do produto, meta da sprint e definição de pronto — estão na nota de artefatos e compromissos do Scrum; aqui ficam os eventos e os timeboxes.

Por que se usa (e o que custa)

Ganha-se cadência. Com data fixa e propósito fixo, cada evento substitui uma enxurrada de reuniões improvisadas: sabe-se quando se decide o quê, e o intervalo entre inspeções nunca passa de um mês, o que limita o tamanho do erro que se pode cometer sem perceber. Ganha-se também previsibilidade de entrega, porque data fixa e escopo variável são a única combinação que permite prometer uma data.

Paga-se em overhead fixo. Uma sprint de um mês reserva até 15 horas para os eventos formais, e esse tempo é gasto mesmo em sprint tranquila. Paga-se também em rigidez deliberada: a meta não muda no meio, e a tentação de esticar a sprint por dois dias para fechar uma funcionalidade precisa ser recusada sempre — é justamente essa recusa que mantém o ritmo mensurável.

Como funciona

A sprint. Duração fixa de um mês ou menos, escolhida pelo time. É o coração do Scrum, onde as ideias viram valor. Durante ela: nenhuma mudança que ponha a meta da sprint em risco, a qualidade não diminui, o backlog do produto é refinado conforme necessário e o escopo é renegociado com o Product Owner à medida que se aprende mais. A sprint pode ser cancelada se a meta se tornar obsoleta, e essa decisão é exclusiva do Product Owner.

Sprint planning. Abre a sprint e responde a três perguntas, nesta ordem: por que esta sprint é valiosa — o que produz a meta da sprint; o que pode ser entregue — os Developers selecionam itens do backlog do produto, com o Product Owner esclarecendo valor e ordem; e como o trabalho será feito — para cada item selecionado, os Developers planejam o necessário para criar um incremento que atenda à definição de pronto, frequentemente decompondo os itens. Só quem executa dimensiona o quanto cabe. O resultado dos três tópicos é o backlog da sprint. Timebox: até 8 horas para sprint de um mês.

Daily scrum. 15 minutos, todo dia útil, no mesmo horário e lugar, para os Developers. Propósito: inspecionar o progresso em direção à meta da sprint e ajustar o backlog da sprint, produzindo um plano acionável para o próximo dia de trabalho. Desde 2020 a estrutura é livre — as três perguntas clássicas deixaram de ser prescritas, e os Developers escolhem técnica e formato desde que o foco e o plano do dia sejam preservados. A daily não é o único momento de conversa: o próprio Guia registra que os Developers costumam se reunir ao longo do dia para discussões mais detalhadas. Em times que usam Kanban, a daily baseada em fluxo desloca o foco das pessoas para os itens de trabalho e o fluxo no quadro.

Sprint review. Penúltimo evento. O time Scrum apresenta o resultado aos stakeholders e juntos inspecionam o incremento e o que mudou no ambiente; o backlog do produto pode ser ajustado para atender a novas oportunidades. É sessão de trabalho, não apresentação passiva, e o que não atende à definição de pronto não pode sequer ser apresentado. Timebox: até 4 horas para sprint de um mês.

Sprint retrospective. Encerra a sprint, depois da review e antes da planning seguinte. Inspeciona como correram indivíduos, interações, processos, ferramentas e a definição de pronto, e planeja formas de aumentar a qualidade e a eficácia do time. As melhorias mais impactantes costumam entrar no backlog da sprint seguinte. Timebox: até 3 horas para sprint de um mês.

Todos os timeboxes acima valem para sprint de um mês e são proporcionalmente menores em sprints mais curtas — em sprint de duas semanas, a planning tende a 4 horas, a review a 2 e a retrospectiva a 1 h 30. A daily é sempre de 15 minutos, qualquer que seja o tamanho da sprint.

O que decide os itens

Evento × propósito declarado — a tabela que resolve a maioria dos itens:

evento	propósito	quem conduz o conteúdo	saída
sprint	conter o trabalho e a meta	time Scrum	incremento
planning	por quê, o quê, como	PO esclarece; Developers planejam o como	backlog da sprint
daily	progresso rumo à meta da sprint	Developers	plano do dia seguinte
review	inspecionar o incremento e adaptar o produto	time Scrum + stakeholders	backlog do produto ajustado
retrospectiva	inspecionar o modo de trabalhar	time Scrum	melhorias para a próxima sprint

Review × retrospectiva — a troca mais explorada do assunto. Ajustar o produto é review; ajustar pessoas, processo e ferramentas é retrospectiva. Inspecionar o incremento ao longo do projeto é função da review, nunca da retrospectiva.

Tempo fixo × escopo variável — o prazo da sprint não se altera para acomodar o trabalho. Quando o item alonga, encurta ou adia um evento para caber a implementação, inverteu o timebox. A única saída prevista é o cancelamento da sprint pelo Product Owner.

Ordem dos eventos — planning, dailies, review, retrospectiva, e só então a planning seguinte, sem intervalo entre sprints. Muitos itens se decidem apenas pela ordem, sem precisar do conteúdo.

Inspeção sempre gera adaptação — os pilares andam juntos. Evento apresentado como barreira a mudanças futuras (“impedir adaptações”) está invertido.

Timebox pertence a evento, nunca a artefato. Duração colada em “sprint backlog” ou em “incremento” já derruba o item antes de se conferir o número.

Antes × depois de 2020 — o Guia de 2020 retirou as três perguntas da daily e a frase que comparava cada sprint a um projeto de horizonte de um mês. Em caderno anterior a 2020, esse vocabulário aparece e é cobrado como correto; o teto de um mês, esse, atravessa todas as versões.

Números que caem

Este é o bloco de memória pura do assunto — e a banca troca um número pelo do evento vizinho.

eventos ao todo	5 — a sprint contém os outros 4
sprint	duração fixa, um mês ou menos
sprint planning	até 8 h (sprint de um mês)
daily scrum	15 min, todo dia útil, mesmo horário e local
sprint review	até 4 h (sprint de um mês)
sprint retrospective	até 3 h (sprint de um mês)
sprints mais curtas	eventos proporcionalmente menores; a daily continua 15 min
total de eventos formais	até 15 h por sprint de um mês, fora as dailies
meta do produto ativa	1 por vez: cumprir ou abandonar antes da próxima

Como a CEBRASPE derruba você aqui

Medido sobre os 24 itens do assunto: 11 são Errados, e a distribuição por rótulo é quase plana — inversão 3, e troca de termo, número errado, atribuição errada e generalização com 2 cada. Nenhum rótulo manda. O que manda é outra coisa, visível só quando se lê o texto dos itens: 7 dos 11 itens errados nomeiam um evento e penduram nele o propósito, o número ou o responsável do evento vizinho. O nome do evento está certo; o que está ligado a ele é que veio do lado errado. É essa ligação que se confere primeiro, e não o vocabulário.

O propósito do vizinho — 3 dos 11, o maior bloco isolado. O item mantém o nome certo e troca a finalidade: a retrospectiva cujo objetivo é “aumentar o reúso de código”, a review que serve para “impedir adaptações futuras”, a retrospectiva “que possui como objetivo principal revisar o burn-down”. Os três soam profissionais e nenhum é o propósito declarado — e note que o segundo não importa outro propósito, ele nega o único que existe: inspeção no Scrum existe para gerar adaptação. Defesa: recite o propósito oficial antes de ler o complemento — produto na review, modo de trabalhar na retrospectiva, plano do dia na daily.

O número do vizinho, e o número preso ao artefato — 2 dos 11. “A sprint retrospective tem um timebox de até quatro horas para sprints de um mês”: quatro é o teto da review, e o item apenas subiu um degrau da escada. O outro é mais barato ainda e se entrega antes do número: “ao final de cada período de duas a quatro semanas de um Sprint backlog” — duração pertence a evento, nunca a artefato, e o limite oficial é um mês ou menos, não uma faixa fechada. Defesa: a escada decrescente 8, 4, 3 e 15 minutos, decorada; e, antes dela, a pergunta de a quem a duração está colada.

O responsável trocado, ou o evento trocado — 2 dos 11, e são os dois itens mais reaproveitáveis do assunto. “Cabe ao product owner planejar o trabalho necessário para criar um incremento”: o como é exclusivo dos Developers, e a frase reaparece caderno após caderno com só o sujeito mudado. E “o time Scrum transforma uma seleção do trabalho em um incremento de valor durante uma daily”: o incremento nasce na sprint, que é o contêiner; a daily só replaneja o dia. Defesa: leia apenas o sujeito do verbo, e depois só o complemento de tempo.

O absoluto do elaborador — 2 dos 11. “Daily scrum é o único momento do dia em que os developers se reúnem” e “as demos são realizadas quando todas as funcionalidades planejadas para o produto estão concluídas”. Os eventos criam regularidade, não proíbem conversa fora deles — o próprio Guia diz que os Developers costumam se reunir ao longo do dia; e adiar a demonstração para o fim do produto elimina a inspeção frequente, que é a razão de ser do ciclo. Defesa: pergunte de quem é o absoluto. “Duração fixa de um mês ou menos” e “não pode ser apresentada na sprint review” são absolutos do Guia e sustentam itens Certos; “único” e “todas” nesses dois são do elaborador.

A direção invertida — 2 dos 11. “O prazo de uma sprint pode ser alterado para se adequar ao tempo de implementação dos itens” inverte o que é fixo e o que é variável. E a daily baseada em fluxo cujo foco “passa a ser as pessoas” — é exatamente o contrário: o foco deixa as pessoas e vai para os itens e o fluxo no quadro. Defesa: em item que descreva deslocamento, ajuste ou acomodação, confira a direção antes do conteúdo.

O lado Certo é uniforme e vale como filtro. Os 13 itens Certos do assunto são todos descrição ou permissão — “pode ser considerada o núcleo”, “podem selecionar a estrutura e as técnicas que quiserem”, “sendo possível ajustar o product backlog” — e nenhum deles restringe por conta própria. Os únicos absolutos entre os Certos são citação do Guia. Quando o item apenas descreve um evento sem acrescentar exclusividade, proibição ou número, a probabilidade está fortemente a favor de Certo; a armadilha entra justamente quando se acrescenta um desses três.

Erros clássicos

Achar que algum evento acontece fora da sprint. Nem a planning: ela abre a própria sprint que planeja.

Esticar a sprint para fechar uma funcionalidade. O prazo é fixo; o escopo é que cede. O único fim antecipado possível é o cancelamento pelo Product Owner, quando a meta se torna obsoleta.

Exigir as três perguntas na daily. Depois de 2020, o formato é livre; o que permanece obrigatório é o foco na meta da sprint e o plano para o dia seguinte.

Inverter review e retrospectiva. Primeiro se inspeciona o produto com os stakeholders, depois o time inspeciona a si mesmo.

Achar que a review é apresentação passiva. Dela saem ajustes no backlog do produto — e nela não se apresenta o que não atende à definição de pronto.

Deixar folga entre sprints. Uma nova sprint começa imediatamente após o término da anterior.