Disciplina de tempo a serviço do valor.
Por Adriane Colossetti
Tem uma cena que se repete em muita empresa que começa a usar Scrum. A Daily marcada para quinze minutos chega aos quarenta. A Planning some com a manhã inteira e o time sai dela sem saber o que vai entregar. A Retrospectiva vira desabafo ou vira silêncio constrangido, dependendo do humor do gestor que resolveu assistir. E aí alguém conclui que “Scrum não funciona aqui”.
Em boa parte dos casos o problema não está no Scrum. Está no entendimento de uma palavra: time-box.
Este artigo é sobre isso. O que o Scrum Guide 2020 define, o que ele deliberadamente não define, e por que o time-box é menos uma regra de agenda do que um instrumento de comportamento.
O que “time-box” quer dizer, sem rodeio
Time-box é um limite de tempo fixado antes de o evento começar. Ele existe por um motivo simples: quando um encontro não tem fim previsto, a conversa tende a se expandir até ocupar o tempo de quem estiver disponível. O time-box força a pergunta que ninguém faz espontaneamente — o que precisa acontecer aqui para que este encontro tenha valido a pena?
Três consequências práticas que costumam passar despercebidas.
O limite não deveria ser negociado no meio do evento. Estender a Planning porque “faltou pouco” é abrir mão do único mecanismo que estava obrigando o time a priorizar naquele momento. O que não coube dentro do time-box é informação valiosa: pode indicar item pouco claro, refinamento insuficiente, ou decisão que dependia de alguém que não estava na sala.
O limite não é uma meta de ocupação. Isso merece uma seção inteira, e vai ter.
E o limite protege o trabalho, não a agenda. Toda hora de evento é hora que não está sendo usada para construir. O Scrum não criou eventos longos por gosto por reunião; criou tetos para que a conversa necessária aconteça e pare.
Os cinco eventos e seus limites no Scrum Guide 2020
O Scrum Guide define cinco eventos. Um deles é o recipiente dos outros quatro.
A Sprint: duração fixa, não duração máxima
A Sprint é o coração do Scrum. O Guia a define como um evento de duração fixa de um mês ou menos, e é dentro dela que todos os outros quatro acontecem. Uma nova Sprint começa imediatamente depois que a anterior termina.
Aqui está a primeira distinção que muita gente erra, e ela é conceitualmente diferente das outras quatro:
Um mês é o teto. Mas a duração que o seu time escolheu é fixa. Se o time trabalha em Sprints de duas semanas, a Sprint tem duas semanas — não “até duas semanas”. Ela não termina antes porque o time acabou o trabalho, e não se estica porque faltou terminar. O que sobra ou falta vira conversa na Review e na Retrospectiva.
Essa constância não é burocracia. É ela que torna a previsibilidade possível: cadência fixa é o que permite comparar uma Sprint com a outra, perceber tendência e conversar com o negócio em intervalos confiáveis. Sprint elástica compromete exatamente o dado que o Scrum tenta produzir.
Uma nota que costuma surpreender: a Sprint pode ser cancelada, e o Guia é explícito ao dizer que só o Product Owner tem essa autoridade. O motivo previsto é a Meta da Sprint ter se tornado obsoleta. É um evento raro, e deveria ser mesmo.
Sprint Planning: até 8 horas
A Sprint Planning abre a Sprint. O Guia a define como limitada a no máximo oito horas para uma Sprint de um mês, e acrescenta que, para Sprints mais curtas, o evento normalmente é mais curto.
O Guia organiza a Planning em três assuntos:
- Por que esta Sprint é valiosa — a Meta da Sprint, que o Scrum Team constrói e que o Product Owner conduz em termos de valor.
- O que pode ser feito — os itens do Product Backlog que os Developers selecionam.
- Como o trabalho escolhido será feito — o plano dos Developers, decisão deles.
Repare em uma coisa: nenhum desses três assuntos é “escrever tarefas até preencher a agenda”. Se a Planning terminou em duas horas com Meta clara e trabalho selecionado, ela terminou.
Daily Scrum: 15 minutos
Quinze minutos. Todo dia útil da Sprint. Mesmo horário e mesmo lugar, para reduzir a complexidade de coordenação.
A Daily Scrum é um evento dos Developers, para inspecionar o progresso rumo à Meta da Sprint e adaptar o plano do dia. O Product Owner e o Scrum Master participam como Developers quando estão trabalhando ativamente em itens do Sprint Backlog — nesse caso estão ali no mesmo papel de todo mundo, não como observadores nem como autoridade. Quando não estão nessa condição, não são participantes do evento.
Duas coisas que o Scrum Guide 2020 não exige, e que muita gente ainda trata como obrigatórias:
As três perguntas não são regra. “O que fiz ontem, o que farei hoje, o que me impede” era estrutura sugerida em versões anteriores e saiu na edição de 2020. Os Developers podem usar a estrutura que quiserem, desde que o evento cumpra a função de inspecionar e adaptar rumo à Meta da Sprint.
A Daily não é reunião de status para gestor. Quando ela vira prestação de contas para quem manda, tende a deixar de servir para o que existe: o time para de expor dificuldade e passa a apresentar boletim.
Um sintoma comum: a Daily que estoura os quinze minutos com frequência. Isso pode indicar resolução de problema técnico acontecendo com plateia, pode indicar que o evento virou status para terceiros, e pode indicar que o Sprint Backlog não está claro o bastante para o time falar dele em quinze minutos. A conversa técnica é legítima; o lugar dela costuma ser depois, com quem interessa.
Sprint Review: até 4 horas
No máximo quatro horas para uma Sprint de um mês, e normalmente mais curta para Sprints mais curtas.
Na Review, o Scrum Team e os principais stakeholders inspecionam o resultado da Sprint e colaboram sobre o que fazer a seguir — o que muda no Product Backlog diante do que foi entregue e do que mudou no ambiente. O Guia é direto ao dizer que ela é uma sessão de trabalho, e que o Scrum Team deve evitar limitá-la a uma apresentação. Essa frase merecia estar pregada na parede de muita empresa: Review não é demo com slide.
Vale registrar que a participação dos stakeholders depende de convite e de disponibilidade real. O evento cria a oportunidade de colaboração com quem está fora do Scrum Team; ele não garante que ela aconteça. Quando a Review acontece sistematicamente sem ninguém de negócio na sala, isso é dado sobre a organização, e merece conversa na Retrospectiva.
Sprint Retrospective: até 3 horas
No máximo três horas para uma Sprint de um mês. Fecha a Sprint.
É o evento especificamente dedicado a planejar formas de aumentar qualidade e eficácia — inspecionando como o trabalho aconteceu em termos de pessoas, interações, processos, ferramentas e Definição de Pronto, e escolhendo melhorias. O Guia sugere que o Scrum Team trate o mais impactante o quanto antes, inclusive incorporando-o à próxima Sprint.
Todos os eventos do Scrum criam oportunidades de inspeção e adaptação — a Sprint Planning, a Daily e a Review também. A particularidade da Retrospectiva é ter como assunto o próprio modo de trabalhar do time, e não o produto.
Na minha experiência conduzindo transformação em empresas, a Retrospectiva é o evento que mais revela a maturidade real de um time — e costuma ser o primeiro a ser sacrificado quando a pressão aumenta. Cortá-la para “ganhar tempo” desliga o espaço formal que o time tinha para melhorar o jeito como trabalha.
Máximo não é meta: o erro que atravessa quase todo time
Aqui está o ponto central deste artigo.
Quando o Scrum Guide diz “no máximo oito horas”, ele está dizendo até. Não está dizendo “reserve oito horas e use todas”. A frase seguinte no Guia — de que para Sprints mais curtas o evento normalmente é mais curto — deixa claro que o limite é um teto, e não uma prescrição de duração.
E ainda assim, o que se vê com frequência é o time bloquear o teto na agenda e depois preencher o buraco. O resultado costuma ser previsível: a conversa se dilata para caber no tempo disponível, discussão que se resolveria em vinte minutos ganha meia hora de rodeio porque ninguém tem pressa, e o time aprende, sem perceber, que evento de Scrum é longo por natureza — o que envenena a adesão de quem entra depois.
A leitura correta é a inversa: o time-box é o ponto onde o evento para, não o ponto onde ele deve chegar. Terminar antes, com o propósito cumprido, é sinal de time maduro. Terminar antes sem o propósito cumprido aponta para outra coisa — e aí o problema raramente é o tempo; costuma ser o refinamento que não aconteceu.
Uma exceção que vale registrar: a Daily é o caso em que o limite e a duração praticada quase coincidem. Quinze minutos é curto o bastante para que “acabar mais cedo” seja incomum, e para que estourar mereça investigação.
Como isso fica em uma Sprint de duas semanas
O Scrum Guide define os máximos para a Sprint de um mês e diz que Sprints menores costumam ter eventos menores. Ele não publica tabela para duas semanas e não estabelece proporcionalidade matemática. O que segue é referência prática de mercado, útil como ponto de partida — e não é regra do Guia:
| Evento | Teto do Guia (Sprint de 1 mês) | Referência prática (Sprint de 2 semanas) |
|---|---|---|
| Sprint Planning | até 8 h | cerca de 4 h |
| Daily Scrum | 15 min | 15 min — não muda com o tamanho da Sprint |
| Sprint Review | até 4 h | cerca de 2 h |
| Sprint Retrospective | até 3 h | cerca de 1 h 30 |
Fazendo a conta com dez Dailies — o caso de uma Sprint de duas semanas com dez dias úteis, sem feriado:
- Sprint Planning: 4 h
- Dez Daily Scrums de 15 min: 2 h 30
- Sprint Review: 2 h
- Sprint Retrospective: 1 h 30
- Total: cerca de 10 horas
São cerca de dez horas de evento em dez dias úteis. O número muda com o calendário: feriado, recesso ou Sprint que começa no meio da semana alteram a quantidade de Dailies e, com ela, o total. Quando um gestor reclama que “Scrum é só reunião”, vale checar se o time está estourando os tetos — porque cumprindo-os, a conta é essa.
Dois exemplos concretos do que muda na prática:
Planning que acaba em duas horas. O time tinha Backlog refinado, Meta clara e itens compreendidos. Sobraram duas horas. A leitura apressada é “planejamos pouco”. A leitura mais provável é que o refinamento contínuo funcionou — e as duas horas voltam para o trabalho.
Review de quarenta minutos com quatro pessoas de negócio presentes e conversando. Costuma valer mais do que duas horas de apresentação em que o time fala e o negócio assiste. O critério de sucesso da Review é a qualidade da inspeção, do diálogo com os stakeholders e das decisões sobre o que fazer a seguir — não a duração da sessão. O Product Backlog pode ser adaptado quando necessário.
O que o time-box revela sobre comportamento e maturidade
Time-box é uma regra de tempo com efeito de comportamento. É por isso que ele funciona tão bem como diagnóstico.
Foco. Limite de tempo obriga escolha. Sem ele, o time tende a discutir o que é confortável — a arquitetura elegante, a ferramenta nova — e a adiar o que é difícil. Com ele, o assunto difícil tende a subir, porque não cabe adiar tudo.
Segurança psicológica. Retrospectiva que termina em vinte minutos com “está tudo bem” pode ser time eficiente, e pode ser time que não se sente seguro para falar. Vale olhar para o que mais está acontecendo: quem fala, quem cala, quem está na sala. O time-box não cria segurança, mas o silêncio dentro de uma hora reservada é informação.
Acordo sobre o que é importante. Quando um time encerra a Planning no prazo com a Meta clara, ele demonstra que já resolveu antes as conversas que precisavam acontecer antes. O time-box mede, em boa medida, o que aconteceu fora dele.
Respeito. Começar no horário e terminar no horário é uma forma concreta de respeito pelo tempo alheio, com efeito cumulativo na confiança do time. É pequeno e é raro.
Cinco sinais de que o time-box está sendo usado errado
- A Daily passa dos quinze minutos com frequência e ninguém trata isso como assunto.
- A Planning ocupa sempre o teto, independentemente do tamanho ou da clareza do trabalho.
- A Review vira apresentação com slides, sem inspeção real, diálogo com stakeholders ou discussão sobre possíveis adaptações.
- A Retrospectiva é a primeira coisa cortada quando o prazo aperta.
- A Sprint “escorrega” alguns dias para caber o que faltou terminar.
O quinto costuma ser o mais grave, porque é o que destrói a cadência — e com ela a previsibilidade que justifica boa parte do resto.
Time-box e geração de valor
A conexão que fecha o raciocínio é esta: o Scrum é um framework leve para gerar valor em ambientes complexos — não é um método para trabalhar mais rápido. Ele existe para ajudar o time a descobrir mais cedo se o que está sendo construído vale a pena.
Cada time-box existe para garantir um ponto de inspeção em intervalo previsível. A Sprint garante que exista um incremento inspecionável em prazo curto. A Review cria a oportunidade de o Scrum Team e os stakeholders olharem juntos para o resultado e decidirem o que vem depois. A Retrospectiva reserva espaço para revisar o próprio modo de trabalhar. Sem limites de tempo, esses pontos de inspeção deslizam — e quando deslizam, o erro tende a ficar caro, porque é descoberto tarde.
Disciplina de tempo, no Scrum, é o que compra a chance de errar barato.
Continue estudando
Se você está se preparando para uma certificação Scrum ou quer aprofundar a atuação como Scrum Master ou Product Owner, os preparatórios da Sunsetti — PSM I, PSM II, PSPO I e PSPO II — trabalham exatamente esse tipo de leitura: o que o Guia diz, o que ele não diz, e como isso se traduz em comportamento de time. Conheça as formações
Perguntas frequentes
Time-box é a mesma coisa que prazo?
Não. Prazo é a data em que uma entrega deve estar pronta. Time-box é o limite de duração de um evento. Um prazo pode ser negociado; um time-box, uma vez definido, é respeitado dentro daquele evento.
Posso estender a Sprint Planning se o time não terminou?
Não é o caminho recomendado. Se o time-box acabou sem Meta clara, isso pode indicar refinamento insuficiente, item mal compreendido ou ausência de quem tinha autoridade de decisão. Estender trata o sintoma e tende a manter a causa.
Preciso usar as três perguntas na Daily?
Não. O Scrum Guide 2020 não prescreve estrutura para a Daily Scrum. O que ele exige é que o evento sirva aos Developers para inspecionar o progresso rumo à Meta da Sprint e adaptar o plano do dia, dentro de quinze minutos.
O Product Owner e o Scrum Master participam da Daily?
Participam como Developers, quando estão trabalhando ativamente em itens do Sprint Backlog. Fora dessa condição, o evento é dos Developers.
Se a Sprint é de duas semanas, quanto tempo deve durar cada evento?
O Guia define os máximos para Sprint de um mês e diz que Sprints menores costumam ter eventos menores, sem publicar tabela e sem estabelecer proporção matemática. Como referência prática de mercado, algo próximo de 4 h de Planning, 2 h de Review e 1 h 30 de Retrospectiva funciona como ponto de partida. A Daily continua com quinze minutos.
O time pode terminar um evento antes do time-box?
Pode, e costuma ser bom sinal quando o propósito do evento foi cumprido. O limite é onde o evento para, não onde ele precisa chegar.
A Sprint pode ser cancelada?
Pode, e só o Product Owner tem autoridade para isso. A situação prevista é a Meta da Sprint ter se tornado obsoleta.
Quem participa da Sprint Review?
O Scrum Team e os principais stakeholders convidados. É uma sessão de trabalho colaborativa, não uma apresentação.
Referência
Scrum Guide 2020 — Ken Schwaber e Jeff Sutherland, novembro de 2020. Versão oficial e traduções, incluindo português: scrumguides.org (o guia em si em scrumguides.org/scrum-guide.html e as traduções em scrumguides.org/download.html).
Os limites de tempo citados neste artigo — um mês para a Sprint, 8 h para a Sprint Planning, 15 min para a Daily Scrum, 4 h para a Sprint Review e 3 h para a Sprint Retrospective, todos referidos a uma Sprint de um mês — vêm do Scrum Guide 2020. A tabela e a soma para Sprints de duas semanas não estão no Guia: são referência prática de mercado, apresentadas como ponto de partida.