Postagens

Como conduzir reunioes de sprint planning que realmente funcionam

O sprint planning e a cerimonia do Scrum que da inicio a cada sprint. A equipe decide o que construir, por que isso importa e, de forma geral, como vao realizar o trabalho. Quando funciona bem, todos saem alinhados. Quando nao funciona, voce tem duas horas de confusao seguidas de duas semanas de caos. A maioria das equipes realiza o sprint planning (cerca de 86% segundo a Scrum Alliance), mas muitas o tratam como uma sessao de leitura do backlog em vez de uma conversa real de planejamento. Veja como fazer da forma correta.

O que o sprint planning realmente produz

O resultado do sprint planning e o Sprint Backlog, que tem tres partes:

• Um Sprint Goal, que e uma declaracao curta sobre por que este sprint importa
• Os itens do backlog selecionados que a equipe se compromete a concluir
• Um plano de entrega de como a equipe pretende transformar esses itens em um incremento funcional

O Sprint Goal e a parte que a maioria das equipes pula, e e a mais importante. Sem ele, o sprint se torna um amontoado de tarefas nao relacionadas, sem uma direcao coerente.

Quem deve estar na sala

Todo o Time Scrum participa:

Papel	O que fazem no sprint planning
Product Owner	Apresenta os itens priorizados do backlog, propoe o Sprint Goal, negocia o escopo
Scrum Master	Facilita a reuniao, controla o timebox, remove impedimentos
Desenvolvedores	Selecionam o trabalho que podem se comprometer a entregar, planejam a implementacao, decompoe historias em tarefas

Especialistas no assunto ou stakeholders podem ser convidados quando sua contribuicao e necessaria, mas sao convidados, nao tomadores de decisao. Um antipadrao comum: enviar apenas um ou dois membros da equipe para "representar" os desenvolvedores. Se as pessoas que vao fazer o trabalho nao participam da conversa de planejamento, os compromissos que lhes sao entregues raramente se sustentam.

A estrutura da reuniao

A reuniao tem um fluxo natural, desde a definicao de objetivos ate o planejamento em nivel de tarefas.

1. Defina o Sprint Goal

   O Product Owner propoe por que este sprint importa e qual valor ele deve entregar. A equipe trabalha junta para refinar isso em um Sprint Goal claro. Se precisar de um ponto de partida, experimente um gerador de sprint goal. Comece aqui, nao pelo backlog. O objetivo da direcao a todo o resto.

2. Revise a capacidade

   Antes de selecionar qualquer trabalho, verifique a disponibilidade real. Quem esta de ferias? Quem esta de plantao? Uma abordagem confiavel: calcule a media da velocidade dos ultimos tres sprints com uma calculadora de velocidade de sprint e ajuste para mudancas de capacidade conhecidas.

3. Selecione os itens do backlog

   O Product Owner apresenta os itens de maior prioridade (que ja devem estar refinados e estimados). Os desenvolvedores selecionam o que estao confiantes de que podem concluir, considerando sua capacidade e a Definition of Done. Isso e uma negociacao, nao uma atribuicao de cima para baixo.

4. Decomponha em tarefas

   Para cada item selecionado, os desenvolvedores dividem o trabalho em tarefas menores, idealmente concluiveis em um dia ou menos. E aqui que complexidades ocultas e dependencias surgem antes de se tornarem surpresas no meio do sprint.

5. Confirme o Sprint Backlog

   A equipe revisa o quadro completo: Sprint Goal, itens selecionados, plano de entrega. Todos devem sair da sala capazes de explicar do que se trata o sprint e no que vao trabalhar primeiro.

Quanto tempo deve durar

O Scrum Guide define maximos, nao metas:

Duracao do sprint	Tempo maximo de planejamento
1 semana	2 horas
2 semanas	4 horas
3 semanas	6 horas
4 semanas	8 horas

Na pratica, a maioria das equipes com sprints de 2 semanas termina o planejamento em 60-90 minutos quando o backlog foi bem refinado anteriormente. Se voce esta consistentemente usando todo o timebox, isso e um problema de refinamento, nao de planejamento.

Onde a estimativa se encaixa

E aqui que as equipes frequentemente erram. A estimativa deve acontecer antes do sprint planning, durante o refinamento do backlog, nao no inicio da reuniao. Mike Cohn, que criou o Planning Poker, identifica dois bons momentos para estimar:

1. Apos workshops de escrita de historias, quando um lote de 20-50 novos itens precisa de dimensionamento
2. Durante sessoes regulares de refinamento, conforme os itens sao esclarecidos ao longo do sprint

E um momento ruim: no inicio do sprint planning. Nessa hora, ja e tarde demais para o Product Owner ajustar prioridades com base em novas estimativas, e os desenvolvedores que estao mentalmente entrando no modo de execucao tem dificuldade com o dimensionamento relativo de alto nivel. Quando o topo do backlog chega ao sprint planning ja estimado, a reuniao se torna um exercicio de selecao ("quanto desse trabalho estimado cabe na nossa capacidade?") em vez de um debate de estimativa. Essa e a diferenca entre uma sessao de 90 minutos e uma de 3 horas. Se sua equipe usa planning poker para estimativa, realize essas sessoes durante o refinamento. Ferramentas como o Kollabe suportam estimativa assincrona para que as equipes possam estimar no seu proprio tempo sem bloquear todo o grupo.

Erros que atrapalham o sprint planning

Backlog mal preparado. Chegar ao planejamento com historias vagas e nao refinadas e a causa numero um de reunioes longas e frustrantes. Se os criterios de aceitacao nao estao claros antes da reuniao, nao ficarao mais claros durante ela. Sem Sprint Goal. Sem um objetivo, nao ha como tomar decisoes de troca quando o escopo fica apertado. Voce acaba com uma lista desconexa de tarefas em vez de um sprint coerente. Comprometimento excessivo. Se voce esta regularmente movendo 30-40% do trabalho nao finalizado para o proximo sprint, esta assumindo mais do que a equipe pode entregar. A maioria das equipes perde 15-25% do sprint com trabalho nao planejado, reunioes e overhead. Leve isso em consideracao. Pular o "como". Selecionar historias sem discutir a implementacao significa surpresas no meio do sprint. Mesmo cinco minutos sobre a abordagem evitam a maioria delas. Tratar como uma reuniao de status. O sprint planning e voltado para o futuro. Se voce esta gastando tempo com atualizacoes sobre o que aconteceu no sprint anterior, isso pertence a sprint review ou retrospectiva.

Melhorando o sprint planning ao longo do tempo

Se voce for melhorar uma coisa, que seja o refinamento do backlog. O Scrum Guide recomenda gastar 5-10% do total de horas do sprint em refinamento. Quando as historias chegam ao planejamento com criterios de aceitacao claros, dependencias conhecidas e estimativas existentes, a reuniao praticamente se conduz sozinha. Alem disso:

• Compartilhe os itens candidatos 1-2 dias antes para que os desenvolvedores possam pensar nas abordagens com antecedencia
• Comece com o Sprint Goal, nao com o backlog. Ele fornece foco e facilita as decisoes de escopo
• Deixe os desenvolvedores serem donos do "como". O Product Owner negocia o que sera construido, os desenvolvedores decidem como
• Reserve capacidade para divida tecnica. Equipes experientes alocam ate 20% do sprint para bugs e refatoracao
• Incorpore itens de acao da retrospectiva. Se a equipe concordou em mudar algo no sprint anterior, isso deve aparecer no plano deste sprint

Sprint planning no contexto geral

O sprint planning e uma cerimonia dentro de um ciclo, e funciona melhor quando as outras tambem estao cumprindo seu papel. As retrospectivas revelam melhorias de processo que alimentam o plano do proximo sprint. As sprint reviews revelam feedback dos stakeholders que moldam as prioridades. Os daily standups adaptam o plano conforme as coisas mudam. E o refinamento do backlog prepara a materia-prima que torna o sprint planning eficiente. Quando o resto do ciclo esta saudavel, o sprint planning se torna a reuniao mais curta, nao a mais longa.