A reunião de planejamento do sprint, passo a passo

O planejamento do sprint é a reunião que dá início a um sprint. Nela, a equipe define uma meta do sprint e decide qual parte do backlog pode, de forma realista, ser concluída — transformando uma lista priorizada em um plano no qual a equipe realmente acredita. Um backlog é uma lista de desejos até que alguém decida o que será desenvolvido em seguida. Essa decisão é o planejamento do sprint.

Quando bem conduzida, leva uma ou duas horas, e a equipe sai sabendo o que está fazendo e por quê. Quando mal conduzida, transforma-se em uma sessão de leitura da lista de tarefas pendentes, na qual o product owner atribui tickets e todos concordam com a cabeça — e o “compromisso” desmorona discretamente já na quarta-feira.

Por que, o quê e como

O Guia do Scrum estrutura o planejamento do sprint em torno de três perguntas, e vale a pena mantê-las nesta ordem:

• Por que esse sprint é valioso? A resposta está na meta do sprint — uma frase que une toda a equipe. Cheguem a um acordo sobre ela antes de começarem a trabalhar no backlog. Definir uma meta de sprint é uma habilidade em si.
• O que pode ser feito neste sprint? Os desenvolvedores selecionam itens do topo do backlog que contribuem para o objetivo, até atingirem o limite de sua capacidade. Trata-se de uma previsão, não de uma promessa feita sob juramento.
• Como o trabalho escolhido será realizado? A equipe divide os itens prioritários em um plano detalhado o suficiente para começar — tarefas, uma abordagem, os riscos óbvios. Não é necessário detalhar cada item até a última subtarefa; basta o suficiente para começar com confiança.

O resultado é um backlog do sprint: a meta, os itens selecionados e o plano para entregá-los.

Primeiro, definir o escopo; depois, traçar o plano

O hábito estrutural mais útil, sem dúvida, é realizar o planejamento em duas etapas distintas, em vez de uma única e confusa.

A primeira parte é o escopo. O proprietário do produto apresenta a meta e os itens candidatos em ordem de prioridade. A equipe faz perguntas para esclarecer dúvidas, verifica cada item em relação à definição de pronto e seleciona tarefas até esgotar a capacidade. Pare por aí. A tentação de encaixar “só mais uma” pequena história é exatamente o que leva os sprints a assumirem mais tarefas do que podem cumprir.

A segunda parte é o planejamento. Agora, a equipe analisa em profundidade os itens selecionados — dividindo-os em tarefas, identificando dependências e combinando quem vai assumir cada parte primeiro. É aqui que você descobre que aquela história que parecia valer um 3, na verdade, representa uma semana de trabalho escondida por trás de um critério de aceitação vago.

Manter as duas coisas separadas evita que a reunião fique oscilando entre “devemos aceitar isso?” e “como faríamos para implementar isso?” a cada item.

O que você precisa ter no quarto

O planejamento do sprint só funciona se os dados necessários já estiverem prontos. A reunião transforma esses dados em um plano; ela não os cria na hora.

• Um backlog refinado e priorizado. Os itens principais já devem ter sido compreendidos e ter uma estimativa aproximada de tamanho. Se for só no planejamento que a equipe vê uma história pela primeira vez, você está realizando o refinamento do backlog na reunião errada — e ela vai se prolongar. O refinamento é a etapa preparatória; o planejamento é a tomada de decisão.
• Um número real de capacidade. Não “duas semanas multiplicadas pelo tamanho da equipe”, mas sim as horas efetivamente disponíveis após férias, reuniões, rodízios de suporte e o tempo perdido com interrupções. Veja planejamento de velocidade e capacidade.
• Toda a equipe. Os desenvolvedores fazem a previsão, portanto, eles precisam estar presentes. O planejamento feito por terceiros gera compromissos pelos quais ninguém se responsabiliza.

Quem administra isso

O Scrum Master atua como facilitador — zela pelo cumprimento do tempo estipulado, mantém as duas etapas separadas e evita que a reunião se desvie para a busca de soluções para todos os casos extremos. O product owner apresenta a meta e o backlog ordenado, e responde às perguntas “por que” e “o que” na hora. Os desenvolvedores decidem quanto vão assumir e como vão implementar.

Esse último ponto é importante: a previsão pertence às pessoas que estão realizando o trabalho. Um plano imposto de cima para baixo e aceito em silêncio não é um compromisso — é uma fila.

Quanto tempo isso deve levar

O Guia do Scrum prevê um tempo de planejamento de até oito horas para um sprint de um mês e, proporcionalmente, menos para sprints mais curtos — ou seja, aproximadamente duas horas por semana de sprint. Um sprint de duas semanas deve ficar em torno de quatro horas, muitas vezes menos quando a equipe já tem um ritmo constante.

Considere isso como um limite máximo, não como uma meta. As equipes que realmente precisam do tempo total disponível quase sempre estão refinando o planejamento durante a reunião. Ajuste os dados de entrada, e a reunião se encurtará por si só. Se você quiser um detalhamento minuto a minuto, o capítulo pauta do planejamento de sprint apresenta um exemplo.

Onde está o problema

Três tipos de falhas são responsáveis pela maioria das reuniões de planejamento mal conduzidas.

A sessão de leitura. O proprietário do produto apresenta os tickets e a equipe ouve. Nenhuma decisão é tomada porque ninguém está decidindo — eles estão apenas sendo informados. O planejamento deve parecer que a equipe está escolhendo, e não que está recebendo tarefas.

O excesso de compromisso. A capacidade é tratada como uma meta ambiciosa. A equipe toma sua melhor velocidade já alcançada como ponto mínimo e acrescenta um pouco mais por uma questão de ambição. Então, um problema de suporte, uma ausência por doença e uma tarefa subestimada transformam o sprint em uma correria. Planeje com base no número modesto, não no heróico.

Planejamento sem um objetivo. A equipe seleciona um conjunto aleatório de tickets sem relação entre si e, quando o sprint fica apertado, não há um critério para decidir o que descartar — então tudo fica um pouco atrasado e nada é entregue de forma satisfatória. É o objetivo que indica quais tickets devem ser abandonados sob pressão.

Prepare os dados de entrada, mantenha o escopo e o plano separados e deixe que a equipe assuma a responsabilidade pela previsão. O restante deste guia aborda cada aspecto em profundidade — comece pela agenda ou acesse o modelo de planejamento de sprint.

Perguntas frequentes

O que é o planejamento de sprint?

O planejamento do sprint é o evento do Scrum que dá início a um sprint. A equipe define uma meta para o sprint, seleciona os itens do backlog que prevê poder concluir e esboça como o trabalho será realizado. Ele responde a três perguntas: por que o sprint é valioso, o que será desenvolvido e como.

Quanto tempo deve durar o planejamento do sprint?

Defina um limite de tempo de cerca de duas horas por semana de sprint — ou seja, aproximadamente duas horas para um sprint de uma semana, quatro para um sprint de duas semanas e até oito para um mês. Esse é um limite máximo, não uma meta. Se você precisar constantemente do tempo total previsto, isso geralmente significa que o backlog não estava pronto no início.

Quais são as etapas principais do planejamento do sprint?

Confirme a capacidade real da equipe para o sprint; chegue a um acordo sobre uma meta para o sprint; selecione itens do backlog que contribuam para essa meta até atingir a capacidade; divida os itens prioritários em um plano viável; e confirme se a equipe acredita na previsão. Primeiro, defina o escopo; depois, planeje — nessa ordem.

Quem conduz o planejamento do sprint?

O Scrum Master facilita o processo e garante que ele seja realizado dentro do prazo definido. O Product Owner apresenta um backlog priorizado e refinado e explica o motivo. Os desenvolvedores decidem quanto trabalho podem assumir e como vão implementá-lo — a previsão é de responsabilidade deles, não do Product Owner.