O sprint planning é a reunião que um time Scrum faz no começo de cada sprint para responder a três perguntas: o que este sprint vai entregar (Sprint Goal), quais itens do backlog entram (Sprint Backlog) e como cada um será construído (quebra e abordagem). No fim da reunião, o time começa a trabalhar com um objetivo de sprint claro e uma lista de tarefas executável.
A versão de 30 segundos
- Frequência: uma vez por sprint, fixa no primeiro dia da iteração;
- Duração: sprint de duas semanas → no máximo 2 horas; sprint de uma semana → 1 hora;
- Participantes: o time Scrum inteiro — desenvolvedores, Product Owner, Scrum Master;
- Resultado: 1 Sprint Goal + 1 Sprint Backlog (quebrado em tarefas executáveis);
- Teste de aprovação: ao sair da reunião, cada membro consegue dizer de memória "isso é o que a gente vai construir neste sprint."
Onde o sprint planning se encaixa no ciclo
Sprint Planning (dia 1)
↓
Daily Standup × 9 dias
↓
Sprint Review (demo) + Sprint Retrospective
↓
Próximo Sprint Planning
O planning consome os produtos do passo anterior: o Product Backlog e as ações de melhoria da última retrospectiva. Como as duas reuniões se conectam: veja o guia de sprint retrospective.
A preparação antes da reunião (metade da eficiência dela)
| Item de preparação |
Responsável |
Padrão |
| Product Backlog ordenado |
Product Owner |
Os primeiros candidatos estão claros o bastante — sem precisar explicar contexto na hora |
| Candidatos refinados |
Product Owner + time dev |
1,5–2× a capacidade do topo da lista está quebrado/estimado |
| Capacidade do time calculada |
Scrum Master |
Dias-pessoa efetivos após férias, reuniões e sobreaviso |
| Arrasto do sprint anterior decidido |
Time dev |
Itens inacabados: voltam ao backlog ou entram neste sprint — decidido antes da reunião |
| Definition of Done pronta |
Time |
Todo mundo concorda com o que significa "pronto" |
Sem um backlog preparado, o planning vira uma reunião de esclarecimento de requisitos — a causa mais comum de estouro de tempo.
Modelo de pauta (exemplo de 2 h para um sprint de duas semanas)
| Hora |
Etapa |
O que acontece |
| 0:00–0:10 |
Definir a meta |
O PO propõe o resultado de negócio buscado; o time condensa num Sprint Goal de uma frase (ex. "admins conseguem exportar relatórios") |
| 0:10–0:50 |
Escolher itens |
Percorrer o backlog em ordem: esse entra? Subtrair até esgotar a capacidade |
| 0:50–1:40 |
Quebrar tarefas |
Para cada item escolhido, quebrar tarefas de 0,5–1 dia e anotar a abordagem técnica; riscos técnicos discutidos se resolvem na hora |
| 1:40–1:55 |
Riscos e dependências |
Dependências externas (APIs de terceiros, designs, outros times), escala de sobreaviso, prioridade dos bugs conhecidos |
| 1:55–2:00 |
Confirmar e se comprometer |
Repetir o Sprint Goal e a lista; todos confirmam; nomear as tarefas de largada do primeiro dia |
Como calcular as três entradas-chave
1. Capacidade
Dias-pessoa efetivos = membros × dias úteis − férias − sobrecusto de reuniões − ajuste de sobreaviso
Exemplo: time de 5 pessoas, 10 dias úteis, 3 dias de falta no total, reuniões fixas custando ~2 dias-pessoa → 45 − 3 − 2 = 40 dias-pessoa efetivos.
2. Velocidade
Pegue a média ou mediana dos story points concluídos nos últimos 3–5 sprints (a mediana aguenta melhor os solavancos). Time novo sem histórico? Estime a partir da capacidade: 1 dia-pessoa ≈ 1 unidade de trabalho efetivo, e migre para story points depois de dois sprints. Mal-entendidos sobre velocidade: veja a FAQ.
3. Estimativa
- Planning Poker é a ferramenta de sempre: todos revelam a carta ao mesmo tempo; itens com muita dispersão são discutidos e reestimados;
- Regra de granularidade: itens acima de 8 pontos são quebrados antes de entrar no sprint;
- Pontos estimam esforço relativo, não horas — nunca use para avaliar performance individual.
Erros comuns e correções
| Erro |
Consequência |
Correção |
| Planejar com 100 % da capacidade |
Zero folga; um bug surpresa derruba o sprint |
Planejar com 80 % da capacidade; deixar espaço para defeitos inesperados e sobrecusto de coordenação |
| O PO só conta os requisitos de boca na reunião |
A reunião vira esclarecimento de requisitos |
Refinar os itens antes da reunião; na reunião, confirmar — não dar aula |
| Escolher itens sem quebrar |
O "como" se improvisa no meio do sprint, tarde demais |
Quebrar em tarefas de 0,5–1 dia e revisar a abordagem técnica |
| A meta é uma lista de itens, não um resultado de negócio |
O time responde por "pronto", não por "útil" |
O Sprint Goal precisa ser uma frase orientada a negócio |
| Bugs do sprint anterior nunca priorizados |
O plano do novo sprint vai ao chão com defeitos surpresa |
Decidir o destino dos bugs arrastados na reunião (ver a seção seguinte) |
Onde ficam os bugs do sprint?
Uma parte do planejamento que costuma ser pulada: quais defeitos este sprint vai tratar e de quem é a triagem rodando. Deixe explícito na reunião:
A lista de bugs arrastados e o destino de cada um (consertar / rebaixar / fechar);
O fluxo dos bugs novos durante o sprint: triagem → classificação (P0 no mesmo dia, P1 neste sprint, P2 pro backlog). Como fazer: o guia de bug triage;
Uma entrada única para os relatórios de bug: os reportes de testores ou usuários precisam trazer passos de reprodução, capturas e erros de Console — e não se espalhar pelos chats de grupo.
O ponto 3 é a alavanca invisível da velocidade do sprint: um relatório com contexto completo deixa o desenvolvedor consertando na hora, sem vai-e-vem. A abordagem do BugCapturer: cada envio anexa automaticamente uma captura/gravação anotada, a URL, o ambiente do navegador e os erros de Console/Network (veja a função de diagnóstico), e os relatórios são enviados automaticamente a um canal do Slack / Microsoft Teams — no planning, os defeitos são classificados direto a partir dos relatórios no canal, sem gastar tempo de reunião com "espera, qual era exatamente o problema?".
FAQ
P: O que é uma reunião de sprint planning?
R: A reunião de planejamento do início de cada sprint no Scrum; decide o escopo (o quê) e a abordagem (como), e produz o Sprint Goal e o Sprint Backlog.
P: O que é sprint planning na visão de um business analyst (BA)?
R: O BA cuida da testabilidade e dos critérios de aceitação: os itens escolhidos trazem condições de aceitação e casos de borda claros, e ele traduz as necessidades dos stakeholders em itens do backlog.
P: Quanto tempo deve durar o planning?
R: Regra de bolso: no máximo 1 hora por semana de sprint — sprint de uma semana, 1 hora; de duas semanas, 2. Estouros normalmente indicam refinamento insuficiente antes da reunião.
P: Como um time remoto faz o planning?
R: Videocall + quadro compartilhado (Jira/Linear/Trello) como sempre; na quebra de tarefas, escrever em paralelo num quadro branco colaborativo — cerca de duas vezes mais rápido que ler os itens em série.
P: No meio do sprint percebemos que o plano era pequeno demais. E agora?
R: Não empurre item nenhum no meio do sprint. Anote e priorize no próximo planning; o urgente passa pela via de triagem P0.