Sprint planning: roteiro para conduzir bem a reunião

O que é a sprint planning

A sprint planning é a reunião que abre cada sprint: o momento em que o time olha para o backlog priorizado e decide, junto, o que vai entregar nas próximas uma ou duas semanas — e por quê. Ela responde três perguntas, nesta ordem: por que esta sprint vale a pena? (o objetivo), o que conseguimos fazer? (a seleção de itens) e como vamos fazer? (a quebra em tarefas). Quem sai de uma boa planning sabe exatamente qual é a primeira coisa a puxar no board na manhã seguinte.

Ela não é uma reunião de status, nem uma apresentação do chefe dizendo o que cada um vai fazer. É uma negociação honesta entre duas partes: quem prioriza (o gestor, o Product Owner, o líder da área) traz os itens mais importantes do backlog; quem executa (o time) avalia o esforço, aponta riscos e diz quanto cabe no período. O resultado é um compromisso coletivo — não uma lista empurrada de cima para baixo.

Se o seu time ainda não trabalha em ciclos, vale ler antes como montar uma sprint: a planning é a porta de entrada do ciclo, mas o ciclo em si (duração, cadência, board) precisa existir primeiro.

Antes da planning: o dever de casa que evita reunião de 4 horas

A planning mais eficiente é aquela em que quase tudo já chega meio decidido. Isso não é trapaça — é preparo. Dois ingredientes precisam estar prontos antes de a reunião começar:

Backlog priorizado e refinado. Os itens do topo do backlog devem chegar à planning já discutidos: com descrição clara, critérios de aceite escritos e dúvidas grandes respondidas. Esse trabalho acontece no refinamento de backlog, uma conversa mais curta no meio da sprint anterior. Quando o refinamento não existe, a planning vira uma sessão de descoberta: o time passa duas horas entendendo o que é cada item em vez de decidir o que entra.

Capacidade do time conhecida. Quantas pessoas estarão disponíveis? Alguém sai de férias, tem treinamento, vai dar suporte a outro projeto? Saber a capacidade real do time na sprint antes de selecionar itens evita o erro clássico de planejar para um time de oito quando só seis vão trabalhar.

Um exemplo fora da TI: a Renata lidera um time de marketing de seis pessoas. Toda quinta-feira da segunda semana da sprint, ela reserva 45 minutos para refinar com o time as próximas campanhas do backlog — o que é a peça, para qual canal, qual o prazo externo. Quando chega a planning da segunda-feira, ninguém pergunta "mas o que é esse item?"; a conversa é só sobre o que entra e o que fica.

O roteiro da planning, passo a passo

O coração deste artigo. Uma planning bem conduzida segue cinco passos, sempre na mesma ordem. Para uma sprint de duas semanas, o conjunto cabe confortavelmente em 60 a 90 minutos.

1. Revisar (ou definir) o objetivo da sprint — 10 minutos

Comece pelo porquê. Antes de falar de itens, o gestor ou PO propõe o objetivo da sprint: uma frase que resume o que o ciclo precisa alcançar. "Deixar o novo fluxo de onboarding pronto para o piloto", "Lançar a campanha do Dia dos Pais nos três canais", "Fechar as pendências da auditoria interna". O objetivo é o critério de desempate de tudo o que vem depois — se um item não contribui para ele nem é urgência real, provavelmente pode esperar.

O time pode (e deve) questionar o objetivo. Se ele for genérico demais ("entregar as tarefas da sprint" não é objetivo, é tautologia), refinem juntos até virar algo que caiba numa frase e que dê para responder com sim ou não no fim do ciclo: alcançamos ou não?

2. Apresentar as prioridades do backlog — 15 a 20 minutos

Quem prioriza apresenta os itens do topo do backlog, um a um, na ordem de importância. Para cada item: o que é, por que importa agora, e qual o critério de aceite (como saberemos que está pronto). Como o refinamento já aconteceu, isso é uma recapitulação rápida, não uma descoberta.

Aqui o time faz as últimas perguntas de entendimento. É o momento de levantar dependências ("essa peça precisa da aprovação do jurídico — já foi pedida?") e riscos ("esse relatório depende de dados que o financeiro só fecha dia 20"). Melhor descobrir agora do que no terceiro dia da sprint.

3. Quebrar em user stories e tarefas — 20 a 30 minutos

Itens grandes viram itens menores. Em times de produto e engenharia, isso normalmente significa quebrar features em user stories e stories em tasks. Em times de outras áreas, significa quebrar uma entrega em passos concretos com dono: a campanha do Dia dos Pais vira "redigir copy dos 3 posts", "aprovar arte com a marca", "agendar publicações", "preparar relatório de resultados".

A regra prática: nenhuma tarefa deveria durar mais que um ou dois dias. Se durar, quebre de novo. Tarefas pequenas dão visibilidade diária de progresso no board e evitam aquele item que fica "em andamento" a sprint inteira sem ninguém saber se está a 10% ou a 90%. No TeamBOX, essa hierarquia já vem pronta — Feature → User Story → Task — e a quebra feita na planning vira o board da sprint na mesma hora, com as tarefas visíveis para todo mundo desde o primeiro dia.

4. Estimar — 15 a 20 minutos

Com os itens quebrados, o time estima o esforço de cada um. A técnica mais comum é atribuir story points — uma medida relativa de esforço — e a forma mais divertida e honesta de chegar neles é o Planning Poker: cada pessoa vota em segredo, todos revelam ao mesmo tempo, e as divergências grandes viram conversa. O valor do jogo não é o número; é o momento em que o Diego vota 2, a Luana vota 8, e a discussão revela que a Luana sabe de uma complicação que o Diego não conhecia.

A estimativa serve para uma coisa só: comparar o total selecionado com a capacidade do time. Se o time costuma entregar cerca de 30 pontos por sprint e a seleção soma 45, algo vai ficar de fora — e é muito melhor tirar agora, na planning, do que descobrir na review que metade não ficou pronta.

5. Fechar o compromisso — 10 minutos

O passo mais importante e o mais pulado. Antes de encerrar, o condutor recapitula em voz alta: "Nosso objetivo é X. Entram estes itens, somando Y pontos. Fulana está de férias na quinta e sexta. Todo mundo confortável com esse plano?" — e espera a resposta de cada pessoa, não um silêncio constrangido que passa por concordância.

Esse fechamento explícito transforma uma lista em compromisso. Quando o time diz "sim" olhando para o plano completo, a sprint deixa de ser "as tarefas que me deram" e vira "o que nós combinamos entregar". A diferença aparece no engajamento dos próximos dez dias úteis.

Timebox: quanto tempo a planning deve durar

O Scrum Guide estabelece um teto de 8 horas para sprints de um mês, proporcionalmente menor para sprints mais curtas. Na prática brasileira, com sprints de 1 a 2 semanas, o alvo saudável é 1 a 2 horas. Mais que isso, com frequência, é sinal de que algo antes da planning está falhando — quase sempre o refinamento.

Trate o timebox como compromisso, não como sugestão. Se a conversa sobre um item passar de dez minutos sem convergir, é sinal de que ele não estava maduro: tire-o da sprint, mande de volta para o refinamento e siga em frente. Um item mal-entendido dentro da sprint custa muito mais caro do que um item adiado.

Dica de condução: escreva a pauta com horários no convite ("14h00 objetivo, 14h10 prioridades, 14h30 quebra, 15h00 estimativa, 15h20 compromisso") e nomeie alguém como guardião do relógio — de preferência revezando a cada sprint, para o papel não virar "a pessoa chata".

Papel do gestor vs. papel do time

A planning tem uma divisão de trabalho clara, e respeitá-la é o que separa um compromisso de uma imposição:

• O gestor (ou PO) decide o o quê e o porquê. Ele traz o backlog priorizado, defende o objetivo, responde por que o item A vem antes do B e negocia com stakeholders externos. Prioridade é responsabilidade dele.
• O time decide o como e o quanto. Ele quebra os itens, estima o esforço e diz quanto cabe na sprint. Estimativa é responsabilidade de quem executa — sempre.

Os problemas aparecem quando os papéis se invertem. Gestor que estima pelo time ("isso aí é rapidinho, dá para fazer em um dia") produz sprints estouradas e um time que aprende a não se comprometer. Time que reprioriza sozinho ("achamos esse item mais interessante") produz entregas desalinhadas do negócio. Cada lado tem seu território; a planning é onde os dois se encontram.

Um detalhe de facilitação: se o gestor é quem conduz a reunião e quem prioriza, ele precisa de disciplina redobrada para não atropelar. Uma alternativa é revezar a condução entre membros do time, deixando o gestor livre para o papel de "dono do backlog" — funciona especialmente bem em times maduros.

Planning para times que não são de tecnologia

O roteiro acima nasceu no desenvolvimento de software, mas nada nele é exclusivo de código. O que muda é o vocabulário; a estrutura fica.

O time de RH da Patrícia, por exemplo, roda sprints de duas semanas. Na planning, o objetivo pode ser "deixar o novo programa de onboarding pronto para a turma de agosto". Os "itens de backlog" são entregas: revisar a trilha do primeiro dia, gravar o vídeo de boas-vindas, fechar o cronograma com os gestores. Cada entrega é quebrada em tarefas com dono, o time estima com camisetas (P, M, G) em vez de pontos, e o compromisso é fechado do mesmo jeito: recapitulação em voz alta e "sim" de cada pessoa.

Duas adaptações costumam ser necessárias fora da TI. Primeiro, a demanda imprevista tende a ser maior — um pedido urgente da diretoria, uma entrevista de desligamento que não espera. A solução não é abandonar a planning, é reservar explicitamente uma fatia da capacidade (por exemplo, 20%) para o imprevisto, e planejar apenas com o restante. Segundo, os prazos externos fixos (data de campanha, prazo legal, evento) pesam mais que a priorização interna — nesses casos, o item entra pela data, e o resto do backlog se acomoda ao redor. O artigo sobre Scrum fora da TI aprofunda essas adaptações.

Erros comuns na sprint planning (e como corrigir)

A planning de 4 horas. O erro mais visível. Na imensa maioria das vezes, a causa raiz é a mesma: itens chegando crus, sem refinamento. A reunião que deveria decidir passa a descobrir. Correção: instituir o refinamento no meio da sprint anterior e devolver ao backlog, sem culpa, qualquer item que chegue imaturo à planning.

Escopo empurrado. O gestor chega com a lista fechada e a "planning" vira comunicado. O time assina embaixo calado, a sprint estoura, e na retro ninguém se sente responsável — porque de fato ninguém se comprometeu. Correção: o gestor traz prioridades; o time diz quanto cabe. Se a conta não fecha, corta-se escopo na planning, não qualidade no meio da sprint.

Planejar para a capacidade ideal. Selecionar itens como se todos fossem trabalhar 100% do tempo, ignorando férias, feriados, suporte e reuniões. Correção: começar a seleção pela conta de capacidade real e deixar folga consciente.

Pular o objetivo. Ir direto para a lista de itens produz sprints que são só "um monte de tarefas" — sem critério de desempate quando surge imprevisto e sem senso de propósito. Correção: nenhum item é discutido antes de o objetivo estar escrito e acordado.

Estimar em coro. A pessoa mais sênior fala primeiro ("isso é uns 3 pontos") e todo mundo concorda por inércia. Correção: votação simultânea e secreta — é exatamente o problema que o Planning Poker resolve.

Não fechar o compromisso. A reunião acaba no meio da estimativa, cada um sai com uma versão diferente do plano. Correção: os últimos dez minutos são sagrados para a recapitulação e o "sim" explícito de cada pessoa.

Um teste rápido para saber se a sua planning está funcionando: pergunte a qualquer pessoa do time, na manhã seguinte, qual é o objetivo da sprint e qual a primeira tarefa dela. Se as duas respostas saírem sem hesitação, a reunião cumpriu o papel. Se saírem de olhos arregalados, você já sabe o que revisar na próxima.