Sprint planning: como conduzir e modelo de pauta
A sprint planning é o evento que abre a Sprint e define o que o time vai perseguir nas próximas semanas. Quando funciona, o time sai com uma meta que todos entendem e um plano que pode mudar sem perder o rumo. Quando não funciona, ela vira uma maratona de quatro horas em que o Product Owner lê o backlog item por item, o time chuta estimativas e todos saem com uma lista longa demais, que vai estourar na segunda semana.
A diferença quase nunca está na reunião em si, mas no que acontece antes dela e na ordem das conversas. O Guia do Scrum 2020 organiza a Sprint Planning em três perguntas. Respondê-las nessa ordem, com o backlog preparado e a capacidade calculada, resolve a maior parte dos problemas.
Abaixo estão o que o Guia diz, o que preparar, o passo a passo da condução, um modelo de pauta com tempos e um exemplo.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
O que é Sprint Planning, segundo o Guia do Scrum
A Sprint Planning dá início à Sprint e estabelece o trabalho a ser feito, num plano criado em colaboração por todo o Scrum Team. Ela é um dos cinco eventos do framework apresentado no guia completo de métodos ágeis e Scrum. O Product Owner garante que os participantes estejam preparados para discutir os itens mais importantes do Product Backlog e como eles se ligam à Meta do Produto. O time pode convidar outras pessoas para dar orientação.
O evento responde a três tópicos:
| Tópico | Pergunta | Quem conduz | Resultado |
|---|---|---|---|
| 1 | Por que esta Sprint é valiosa? | Product Owner propõe; Scrum Team decide | Meta da Sprint |
| 2 | O que pode ser feito nesta Sprint? | Developers, com o Product Owner | Itens selecionados do Product Backlog |
| 3 | Como o trabalho escolhido será feito? | Developers | Plano de entrega, muitas vezes em tarefas de um dia ou menos |
A Meta da Sprint, os itens selecionados e o plano formam juntos o Sprint Backlog. O timebox é de no máximo oito horas para uma Sprint de um mês; em Sprints mais curtas, o evento costuma ser mais curto.
Dois detalhes do Guia costumam ser ignorados. Primeiro, a Meta da Sprint precisa estar definida antes de o evento terminar. Segundo, ninguém além dos Developers diz a eles como transformar os itens em Incremento. O Product Owner pode esclarecer e negociar escopo, mas não distribui tarefas.
Antes da reunião: o que preparar
Uma Sprint Planning curta e produtiva depende de quatro insumos prontos:
- Product Backlog refinado no topo. Os itens candidatos devem estar claros e pequenos o suficiente para caber numa Sprint. Uma regra prática é ter refinado o equivalente a uma ou duas Sprints de trabalho. Se o time descobre na planning que não entende os itens, a reunião vira refinamento.
- Capacidade do time. Férias, feriados, treinamentos, plantões e dedicação parcial reduzem o tempo disponível. Calcule antes (veja a seção sobre capacidade).
- Dados das últimas Sprints. Quanto o time costuma concluir. O Guia cita o desempenho passado, a capacidade prevista e a Definição de Pronto como referências para a seleção.
- Proposta de valor do Product Owner. Uma ideia de por que esta Sprint importa, ligada à Meta do Produto. Ela será discutida, não imposta.
O Scrum Master confere que esses insumos existem e, se não existirem, que o time saiba disso antes de começar.
Como conduzir a sprint planning: passo a passo
- Abra com o contexto (10 minutos). O Product Owner lembra a Meta do Produto e o que mudou desde a última Sprint Review: feedback das partes interessadas, decisões da diretoria, prazos externos.
- Discuta o valor e esboce a meta (20 a 30 minutos). O Product Owner propõe o que tornaria a Sprint valiosa. O time discute, faz perguntas e chega a um primeiro rascunho da Meta da Sprint. Ela pode ser ajustada depois da seleção, mas precisa existir antes.
- Confira a capacidade (5 minutos). Os Developers confirmam o número calculado. Se algo mudou (alguém adoeceu, um incidente está em curso), ajuste agora.
- Selecione os itens (30 a 60 minutos). Os Developers puxam itens do topo do backlog que servem à meta, até o limite que julgam realista. Quando surgir dúvida, esclareça com o Product Owner; quando um item for grande demais, divida-o ali mesmo ou troque por outro.
- Feche a Meta da Sprint (10 minutos). Reescreva a meta com base no que foi selecionado. Um bom teste: se no meio da Sprint o time precisar cortar um item, a meta ajuda a decidir qual?
- Planeje o como (30 a 60 minutos). Os Developers decompõem os primeiros itens em tarefas, identificam dependências e decidem por onde começar. Não é preciso detalhar tudo: o plano é refinado ao longo da Sprint.
- Confirme o compromisso (5 minutos). Pergunte ao time se a meta é alcançável. Se houver hesitação, reduza o escopo agora, e não na metade da Sprint.
- Torne o Sprint Backlog visível. Quadro atualizado, meta escrita no topo, primeiros itens com responsável pelo início do trabalho.
Modelo de pauta de sprint planning
Para uma Sprint de duas semanas, um time de seis a oito pessoas costuma conseguir em até três horas. Adapte os tempos à realidade do seu time:
| Bloco | Tempo | Conduz | Saída |
|---|---|---|---|
| Contexto: Meta do Produto e novidades da Review | 10 min | Product Owner | Todos com o mesmo contexto |
| Tópico 1: por que esta Sprint é valiosa | 25 min | Product Owner, com o time | Rascunho da Meta da Sprint |
| Capacidade disponível | 5 min | Developers | Capacidade confirmada |
| Tópico 2: seleção dos itens | 50 min | Developers | Lista de itens selecionados |
| Intervalo | 10 min | ||
| Fechamento da Meta da Sprint | 10 min | Scrum Team | Meta final, escrita |
| Tópico 3: como faremos o trabalho | 50 min | Developers | Tarefas dos primeiros itens, dependências |
| Confirmação e ajustes | 10 min | Scrum Master facilita | Sprint Backlog fechado |
Se a sua planning passa regularmente do tempo, a causa raramente está na pauta. Quase sempre é refinamento insuficiente, e a solução é investir nele durante a Sprint anterior.
Como calcular a capacidade do time
A capacidade é o tempo realmente disponível para trabalhar nos itens da Sprint. Um cálculo simples, para uma Sprint de dez dias úteis, em dias de trabalho:
| Pessoa | Dias úteis | Ausências | Dedicação ao time | Dias disponíveis |
|---|---|---|---|---|
| Developer A | 10 | 0 | 100% | 10 |
| Developer B | 10 | 2 (férias) | 100% | 8 |
| Developer C | 10 | 1 (feriado local) | 100% | 9 |
| Developer D | 10 | 0 | 50% | 5 |
| Developer E | 10 | 0 | 100% | 10 |
| Total | 42 |
Desconte ainda o tempo dos eventos e uma margem para imprevistos e suporte, que o próprio time conhece pela experiência. Se o time estima em pontos, compare a capacidade desta Sprint com a das anteriores: com 20% menos dias disponíveis, faz sentido esperar algo em torno de 20% menos entrega. A técnica de estimativa mais comum para esse cálculo está no artigo sobre planning poker e story points.
Exemplo de sprint planning
O exemplo é ilustrativo. Uma faculdade privada está construindo um portal de rematrícula on-line. A Meta do Produto é que os alunos façam a rematrícula sem ir à secretaria no próximo semestre. É a Sprint 4, de duas semanas.
Contexto: na Review anterior, a secretaria mostrou que boa parte dos atendimentos presenciais é de alunos com pendência financeira, que hoje não conseguem avançar no portal.
Proposta do Product Owner: permitir que o aluno com pendência veja o motivo e negocie, sem travar no meio do processo.
Seleção: os Developers, com 42 dias disponíveis (de 45 possíveis com a dedicação de cada um) e uma média recente de 30 pontos por Sprint, planejam algo perto de 28 pontos e selecionam três itens: exibir pendências na tela de rematrícula, gerar boleto de acordo a partir das regras do financeiro e liberar a rematrícula após a confirmação de pagamento. Um quarto item, de relatórios para a secretaria, fica fora.
Meta da Sprint: "O aluno com pendência financeira consegue identificar o problema e regularizar a situação pelo portal, sem atendimento presencial."
Como: o time decide começar pela integração com o sistema financeiro, que é o maior risco, e divide o primeiro item em tarefas de até um dia. Uma dúvida sobre regras de desconto fica registrada para o Product Owner resolver até o segundo dia.
Erros comuns na sprint planning
- Começar pelo "o que" sem o "por que". Sem meta, a Sprint vira uma lista de tarefas, e qualquer interrupção parece tão importante quanto o trabalho planejado.
- Product Owner definindo quanto cabe. A seleção é dos Developers. Pressão para "caber mais" produz Sprints que nunca fecham.
- Detalhar todas as tarefas de todos os itens. O plano do primeiro dia precisa estar claro; o resto é refinado ao longo da Sprint.
- Planning sem refinamento prévio. A reunião vira sessão de descoberta e passa do tempo.
- Ignorar a capacidade real. Feriados e férias somem do cálculo e o time "falha" sem ter tido chance.
O lugar da planning no ciclo, com o que entra e o que sai de cada evento, está no artigo sobre eventos do Scrum, e as regras da própria Sprint, como duração e cancelamento, em o que é Sprint no Scrum.
Para a sua próxima planning
Na próxima Sprint, faça três mudanças: calcule a capacidade antes da reunião, comece pela pergunta "por que esta Sprint é valiosa?" e não encerre sem a meta escrita no topo do quadro. Depois, na retrospectiva, pergunte ao time se a meta ajudou a tomar decisões durante a Sprint. Para dominar a Sprint Planning junto com os demais eventos e artefatos, o curso Agile Scrum Foundation da Projeto Diário percorre o framework em vídeo, no seu ritmo, e prepara para o exame ASF.
