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. O 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 do backlog, 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 é importante? A resposta está na meta do sprint: uma frase em torno da qual toda a equipe pode se unir. 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 selecionado será realizado? A equipe divide os itens prioritários em um plano detalhado o suficiente para dar início ao trabalho: tarefas, uma abordagem e 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 é realizar o planejamento em duas etapas distintas, em vez de uma única etapa pouco definida.

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 se cada item atende à definição de pronto e retira 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 compromissos excessivos.

A segunda parte é o planejamento. Agora, a equipe se aprofunda nos 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 3 pontos, 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 construir isso?” a cada item.

O que você precisa ter no quarto

O planejamento do sprint só funciona se os dados de entrada 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 na reunião de planejamento que a equipe vir uma história pela primeira vez, você está fazendo o refinamento do backlog na reunião errada, e ela vai se prolongar. O refinamento é o que alimenta; o planejamento é a 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 prazo, 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 quê” e “o quê” na hora. Os desenvolvedores decidem quanto vão assumir e como vão implementá-lo.

Esse último ponto é importante: a previsão pertence às pessoas que estão realizando o trabalho. Um plano imposto 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; portanto, 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 de todo o tempo previsto quase sempre estão refinando o trabalho durante o planejamento. Organize bem as informações a serem discutidas, e a reunião se encurtará naturalmente. 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, pois 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 atribuições.

O excesso de compromisso. A capacidade é tratada como uma meta ambiciosa. A equipe toma como base a sua melhor velocidade já alcançada e acrescenta um pouco mais por uma questão de ambição. Então, um problema de suporte, uma licença médica e uma tarefa subestimada transformam o sprint em uma correria. Planeje com base em um número modesto, não em um número 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; assim, 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 as informações necessárias, mantenha o escopo e o plano separados e deixe que a equipe assuma a responsabilidade pela previsão. O restante deste guia aborda cada um desses aspectos em profundidade. Comece pela agenda ou utilize o modelo de planejamento de sprint.

Perguntas frequentes

O que é o planejamento do 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; portanto, 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 desde o 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: cabe a eles fazer a previsão, e não ao Product Owner atribuí-la.