Vamos falar sobre a Sprint Planning, o primeiro evento numa Sprint do Scrum. Nela acontece o planejamento do que o time buscará realizar, o objetivo a cumprir e o desenho de um plano, ou seja, as ações necessárias para cumprir com uma entrega de valor dentro dos próximos 30 dias ou menos.

Como funciona a Sprint Planning?

O evento tem um timebox (tamanho máximo) de 8 horas para Sprints de 30 dias e geralmente utiliza de menos tempo para Sprints menor duração. Os participantes são todos os membros do Time Scrum: Product Owner, Scrum Master e Development Team. Assim como em todos os eventos do Scrum, na Planning temos um input (entrada de informações), um processamento (entendimento, discussão e tomada de decisão) e um output (saída de um plano).

Quais são os inputs da Sprint Planning?

O elemento mais simples (e óbvio) trazido como entrada para a Planning é o Product Backlog (PB). O PB é uma lista extensa e ordenada contendo os desejos e características funcionais e não funcionais que devem ser parte do produto, serviço ou solução a ser construída.

O segundo elemento trazido para a Planning são a capacity e velocity do time. Mas o que que significa isso? A capacity representa a capacidade de trabalho do time, seja a quantidade de pessoas e a quantidade de dias da Sprint. Por exemplo, precisamos saber se todos do time estarão presentes todos os dias da Sprint, se alguém sairá de férias ou terá de ausentar para uma consulta médica. Nessa Sprint temos todos os dias “úteis” e dedicados ou teremos um feriado, treinamento ou evento corporativo?

Outro item a ser considerado é velocity ou velocidade do time. Isso diz respeito ao histórico de quanto de trabalho esse time conseguiu executar nas Sprints anteriores. Todos esse itens nos ajudarão a fazer um bom planejamento.

O terceiro elemento trazido para a Sprint Planning é a Definition of Done ou Definição de Pronto. Esse item é essencial pelo simples fato que estamos executando um planejando das atividades de trabalho para a Sprint. Para termos um planejamento mais assertivo, é necessário que todos os membros do time tenham um mesmo conceito de completude. Quais as atividades devem ser preenchidas para que cada item da Sprint possa ser considerado pronto?

Por último, temos o plano de melhoria que foi gerado na Retrospectiva da Sprint anterior. Por que isso deve fazer parte da Planning? Pelo simples fato que ao menos uma ação de melhoria traçada na Retrospectiva da última Sprint deve fazer parte da Sprint atual. Isso é uma regra que obriga o time Scrum a ter dinâmica de melhoria contínua e toma tempo do time, e portanto, deve ser considerada no planejamento.

O processamento da Planning

Dentro da Planning acontecerá o processamento de todos esses inputs mencionados. O time terá um momento de alinhamento, discussão, priorização, estimativa, criação para que possa construir um plano para Sprint que se inicia.

Não existe uma regra formal para executar a Planning. O framework Scrum permite o formato que o time achar conveniente. Uma sugestão pode ser o Product Owner iniciar com uma explicação sobre os primeiros itens do Product Backlog, que são os itens de maior prioridade. O Time de Desenvolvimento pode fazer a estimativa ou quebrar esses itens em tarefas menores, caso isso já não tenha sido feito numa atividade de refinamento.

O Time de Desenvolvimento determina a quantidade de trabalho que pode realizar dentro da Sprint. Isso geralmente é feito por heurísticas (práticas complementares), ou seja, não fazem parte do Scrum e cada time escolhe a prática que mais se adequa. A prática mais conhecida de estimativa é o Planning Poker, porém estimativas em horas ou projeções estatísticas (Probabilistic Forecast) da quantidade de trabalho que o time consegue executar também podem ser utilizadas.

Quais os outputs da Sprint Planning?

São três os elementos resultantes da Planning. Esses itens são uma decomposição um do outro e podem ser sintetizados pelas expressões PORQUE, O QUE e COMO.

O primeiro elemento é o Sprint Goal que simboliza uma meta a ser alcançada na Sprint, demonstra um objetivo comum compartilhado e um PORQUE para o time.

Em segundo lugar temos o Sprint Backlog que por sua vez pode ser dividido em duas partes. A primeira parte do Sprint Backlog é composto por O QUE nós vamos fazer. Esses são os PBIs (Itens do Product Backlog) que o time escolhe fazer dentro da Sprint, sendo uma previsão do que o time consegue construir. E por último vem o COMO o time vai trabalhar. São as tarefas que o time vai executar para implementar os PBIs.

Resumindo, temos o Sprint Goal (PORQUE) que pode ser atingido por meio dos PBIs (O QUE), que podem ser implementados por meio das tarefas (COMO), ambos são sintetizados no Sprint Backlog.

Esses são os Inputs, Processamento e Output de uma Sprint Planning. O grande princípio a ser levado em conta é, como tudo no Scrum, que seu time deve inspecionar o melhorar continuamente. Avalie o que estão fazendo, teste novas abordagens e reestruture a Planning para que seja mais efetiva possível na construção de um plano para a próxima Sprint.

Te vejo na próxima, Scrum On!

Momento curiosidade:
Você sabia que a Sprint Planning tinha um outro formato no passado?
Não sei há quanto tempo você já trabalha com Scrum, mas se for há mais de 5 anos, com certeza já ouviu falar dos termos Sprint Planning 1 e Sprint Planning 2. Pode ser que alguns desavisados ainda utilizam esses termos, porém eles não fazem mais parte da definição do framework Scrum. Por volta de 2013 o Scrum Guide foi revisto e Planning passou a ser um evento único, sem as tais divisões.