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 feito, leva uma ou duas horas, e a equipe sai sabendo o que está fazendo e por quê. Quando mal feito, vira uma sessão de leitura da lista de tarefas pendentes, em que o product owner atribui tickets e todos concordam com a cabeça, e o “compromisso” vai se desintegrando discretamente até 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 una 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 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 de todos é 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 se cada item atende à 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 compromissos excessivos.

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 3, na verdade, representa uma semana de trabalho escondida por trás de um critério de aceitação vago.

Manter essas duas questões separadas evita que a reunião fique oscilando entre “devemos adotar 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 a equipe estiver vendo uma história pela primeira vez durante o planejamento, 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. Consulte os tópicos sobre velocidade e planejamento de 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, além de responder às perguntas “por que” e “o quê” na hora. Os desenvolvedores decidem quanto trabalho assumirão e como irão implementá-lo.

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 até oito horas para o planejamento de um sprint de um mês e, proporcionalmente, menos para sprints mais curtos, o que equivale a aproximadamente duas horas por semana de sprint. Um sprint de duas semanas deve ficar em torno de quatro horas, sendo que esse tempo costuma ser menor quando a equipe já estabeleceu 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 plano durante o planejamento. 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 sobre a pauta do planejamento de sprint apresenta um exemplo.

Onde as coisas dão errado

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 tarefas.

O excesso de compromisso. A capacidade é tratada como uma meta ambiciosa. A equipe toma sua melhor velocidade já alcançada como ponto de partida 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 história 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; 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 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 um desses aspectos em profundidade. Comece pela pauta 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 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 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: cabe a eles fazer a previsão, e não ao Product Owner atribuí-la.