Timebox no Scrum: por que cada evento tem tempo máximo
Toda reunião que estoura o horário começa do mesmo jeito: "só mais um ponto". No Scrum, esse "só mais um" tem limite escrito: cada evento do framework tem um tempo máximo, chamado timebox. Scrum sem timebox vira uma sequência de reuniões que não acabam. O limite existe para forçar o time a decidir com a informação que tem, em vez de adiar a decisão esperando a informação perfeita.
O Guia do Scrum 2020 não traz um capítulo sobre timebox, mas os limites aparecem em cada evento, e uma das responsabilidades do Scrum Master é garantir que todos os eventos aconteçam, sejam positivos e produtivos e fiquem dentro do timebox. Quem já viu uma Sprint Planning de seis horas terminar sem meta sabe por que essa responsabilidade foi parar no texto.
A seguir estão os limites de cada evento, a lógica por trás deles, como adaptá-los a Sprints mais curtas e o que fazer quando o tempo acaba antes da conversa.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
O que é timebox e de onde vem o timeboxing
Timebox é um intervalo de tempo fixo e máximo reservado para uma atividade. Quando o tempo acaba, a atividade acaba, e o que ficou de fora vira decisão consciente, e não atraso silencioso. Timeboxing é o ato de trabalhar assim.
A técnica é anterior ao Scrum e aparece em outros métodos de desenvolvimento, como o DSDM, além de ser usada como técnica de produtividade pessoal: reservar 45 minutos para escrever um relatório e parar quando o alarme toca, por exemplo. No Scrum, ela ganhou um papel estrutural: todos os eventos são limitados no tempo, e a própria Sprint é um timebox de no máximo um mês.
O timebox de cada evento do Scrum
| Evento | Timebox no Guia do Scrum 2020 | Tipo de limite |
|---|---|---|
| Sprint | Um mês ou menos | Duração fixa, definida pelo time e mantida |
| Sprint Planning | Até 8 horas para uma Sprint de um mês | Máximo |
| Daily Scrum | 15 minutos | Duração fixa |
| Sprint Review | Até 4 horas para uma Sprint de um mês | Máximo |
| Sprint Retrospective | Até 3 horas para uma Sprint de um mês | Máximo |
Duas observações evitam confusão:
- Planning, Review e Retrospective têm limite máximo. Se o propósito foi atingido em menos tempo, o evento termina. Ninguém precisa "preencher" as 8 horas.
- A Sprint e a Daily têm duração fixa. A Sprint não termina mais cedo porque o trabalho acabou (o time puxa mais itens ou melhora o que fez) e não se estende porque faltou trabalho. A Daily é de 15 minutos, todo dia útil da Sprint, no mesmo horário e lugar.
O refinamento do Product Backlog não aparece na tabela porque, no Guia de 2020, ele é uma atividade contínua, não um evento. Não há timebox oficial para ele.
Como ajustar a Sprints mais curtas
O Guia diz apenas que, em Sprints mais curtas, os eventos costumam ser mais curtos. Uma referência prática comum é reduzir proporcionalmente:
| Duração da Sprint | Planning (máx.) | Review (máx.) | Retrospective (máx.) |
|---|---|---|---|
| 4 semanas | 8 h | 4 h | 3 h |
| 3 semanas | 6 h | 3 h | 2 h 15 |
| 2 semanas | 4 h | 2 h | 1 h 30 |
| 1 semana | 2 h | 1 h | 45 min |
Essa proporção não é regra do Guia. É um teto razoável para começar. Times maduros, com backlog bem refinado, costumam ficar bem abaixo dela.
Por que cada evento tem tempo máximo
O limite de tempo parece uma regra de etiqueta de reunião, mas resolve problemas mais profundos:
- Força a priorização. Com tempo limitado, o time discute primeiro o que mais importa. Sem limite, a conversa segue a ordem de quem fala mais alto.
- Torna o desperdício visível. Se a Planning estoura toda Sprint, o problema não é a Planning: é o backlog mal refinado que chega nela. O timebox expõe o sintoma.
- Protege o tempo de trabalho. Os eventos existem para inspecionar e adaptar, não para substituir o trabalho. O Guia diz que eles servem para criar regularidade e reduzir a necessidade de reuniões que o Scrum não prevê.
- Combate a tendência de o trabalho se expandir. A observação popular conhecida como lei de Parkinson diz que o trabalho se expande até ocupar o tempo disponível. Reunião sem fim tende a confirmar a regra.
- Gera ritmo. Eventos com duração previsível no mesmo dia e horário reduzem a carga de coordenação. Todo mundo sabe quando vai ser chamado e por quanto tempo.
A Sprint como timebox merece destaque. O limite de um mês existe, segundo o Guia, porque horizontes longos aumentam o risco de a meta perder a validade e de a complexidade crescer. O artigo sobre o que é Sprint no Scrum explica a duração e as regras do ciclo em detalhe.
Como facilitar para que o timebox seja respeitado
Respeitar o timebox não é cortar a conversa no meio. É preparar o evento para que ele caiba no tempo. Um roteiro que funciona para qualquer evento:
- Deixe o propósito escrito no início. "Sair com a Meta da Sprint e um plano para os dois primeiros dias" é melhor do que "fazer a Planning".
- Divida o tempo em blocos. Numa Planning de 4 horas, por exemplo: 30 minutos para o porquê, 90 para o quê, 90 para o como e 30 de folga.
- Mostre o relógio. Um temporizador visível, na sala ou na tela compartilhada, faz mais pelo timebox do que qualquer pedido de objetividade.
- Estacione o que não é do evento. Um quadro ou lista de "assuntos para depois" tira a discussão paralela sem ignorá-la.
- Encerre no horário, mesmo sem consenso total. Registre o que ficou aberto e quem vai tratar.
- Leve o estouro para a Retrospectiva. Se o tempo não bastou, a pergunta certa é por quê, e não como estender o limite.
O caso da Daily de 15 minutos
A Daily é o evento em que o timebox mais estoura, porque vira reunião de status ou sessão de resolução de problemas. A saída é separar: a Daily serve para os Developers inspecionarem o progresso rumo à Meta da Sprint e ajustarem o plano do dia; discussões detalhadas acontecem logo depois, só com quem precisa. O guia de como conduzir a Daily Scrum traz formatos e exemplos de pauta.
Erros comuns com o timebox
- Tratar o máximo como duração obrigatória. Uma Retrospectiva de duas semanas não precisa durar 1h30 se o time resolveu o essencial em 50 minutos.
- Estender a Sprint para "fechar" itens. O que não ficou pronto volta para o backlog. Estender esconde o problema de estimativa ou de tamanho dos itens.
- Cortar eventos para ganhar tempo. Pular a Retrospectiva "porque o prazo apertou" elimina justamente o momento de entender por que o prazo apertou.
- Marcar reuniões extras para compensar. Se o time precisa de três reuniões fora do Scrum por semana, os eventos não estão cumprindo o propósito.
- Usar o timebox como pressão. O limite serve para focar a conversa, não para apressar o time a aceitar uma meta irreal.
Timeboxing além dos eventos
A mesma lógica funciona em outras situações de projeto. Exemplos ilustrativos:
- Spikes de pesquisa: "dois dias para descobrir se a integração com o sistema legado é viável". No fim, o time decide com o que aprendeu.
- Workshops com áreas de negócio: num projeto em órgão público, uma oficina de requisitos de três horas, com pauta dividida em blocos, rende mais do que uma tarde inteira sem limite.
- Agenda pessoal: blocos fixos de foco para tarefas que tendem a se espalhar, como responder e-mails ou revisar documentos.
Em todos os casos, o princípio é o mesmo dos eventos do Scrum: o tempo é fixo, e o que varia é o escopo do que se consegue fazer dentro dele. A visão de conjunto dos cinco eventos e de como um alimenta o outro está em eventos do Scrum.
O que fazer agora
Na próxima Sprint, anote a duração real de cada evento ao lado do timebox. Depois de duas Sprints, você terá dados para levar à Retrospectiva: qual evento estoura, quanto e por quê. Para encaixar os eventos no panorama completo do ágil, veja o guia completo de métodos ágeis e Scrum. E, para dominar as regras do framework com método e se preparar para a certificação, o curso Agile Scrum Foundation da Projeto Diário percorre eventos, papéis e artefatos com exemplos práticos.
