O Planejamento da Sprint é um dos cinco eventos do Scrum, sendo aquele que inicia a Sprint. O objetivo dele é definir o que pode ser entregue e como alcançar esse trabalho.

Assim, o Sprint Planning, como é chamado em inglês, é feito em colaboração com todo o time Scrum. O Product Owner garante o preparo de todos os participantes para discutir os itens mais importantes do Product Backlog, e como eles devem mapear esses itens para a meta do produto.

O time Scrum também pode convidar outras pessoas para participar do Sprint Planning, a fim de que forneçam conselhos.

Mas afinal, como planejar uma boa sprint conforme o Scrum Guide? É o que vou te contar agora!

Tópicos da Sprint

Como você deve saber, a Sprint é uma iteração, ou seja, uma parte do projeto a ser entregue dentro de um período específico. Porém, antes que se possa entrar em ação, é preciso planejá-lo.

O Sprint Planning aborda três tópicos:

• Tópico um: por que esta Sprint é valiosa?

O Product Owner propõe como o produto pode aumentar seu valor e utilidade na Sprint atual.

Então, todo o time Scrum colabora para estabelecer um objetivo da Sprint, que define por que ela é valiosa para as partes interessadas. 

Claro, o objetivo da Sprint deve ser alcançado antes do final do Sprint Planning.

• Tópico dois: o que pode ser feito nessa Sprint?

Através de discussão com o Product Owner, os desenvolvedores selecionam itens do Product Backlog para incluir na Sprint atual.

Logo, o time Scrum pode refinar tais itens durante o processo, aumentando assim a confiança e o entendimento.

No entanto, o desafio está em conseguir selecionar o que se pode concluir em uma Sprint. Quanto mais os desenvolvedores souberem sobre o desempenho anterior, a capacidade futura e a Definição de Pronto (Definition of Done), mais confiantes estarão sobre suas previsões.

• Tópico três: como executar o trabalho que selecionaram para a Sprint?

Aqui, para cada item que selecionaram do Product Backlog, os desenvolvedores planejam o trabalho necessário para criar um incremento que atenderá ao Definition of Done.

Geralmente, isso é feito por meio da divisão de itens do Product Backlog em itens de trabalho menores de um dia ou menos – isso, na realidade, fica a critério dos desenvolvedores. 

Em suma, o tópico 1 aborda por que a Sprint tem valor e contribui para a meta do produto. O tópico 2 estipula quantos itens do backlog que priorizaram poderão implementar. Já o tópico 3 trata principalmente dos aspectos técnicos de como desenvolverão o incremento que planejaram.

Como planejar uma boa Sprint?

Portanto, para que um Sprint Planning seja um sucesso, é preciso levar em consideração certos pensamentos.

A execução de um bom evento de Sprint Planning exige – pelo menos um pouco – de disciplina. O Product Owner deve estar preparado para definir o cenário para a Sprint, por isso pode combinar lições da revisão do Sprint anterior, visão do produto e feedback das partes interessadas.

Para dar ainda mais transparência ao processo, pode-se atualizar e refinar o Product Backlog, embora isso nem sempre seja necessário, ok? 

Tempo limite

Além disso, é importante definir um tempo limite para o Planejamento da Sprint: que deve se restringir ao máximo de duas horas por cada semana da Sprint. Esse limite é o famoso timeboxing (caixa de tempo) – a definição de uma duração máxima de tempo para o time planejar a Sprint.

O Scrum Master é o responsável por garantir que a reunião aconteça e que esse limite seja compreendido.

Uma dica é focar essa primeira parte do Sprint Planning no objetivo da Sprint e não nos detalhes do Backlog. Focando na meta ao invés do trabalho, será possível encontrar formas inteligentes para a forma de como alcançar essa meta.

Ainda, mantenha o foco nos resultados e não no trabalho. 

Durante o Sprint Planning, é normal que o time fique “atolado” no trabalho, o que faz com que se concentre em qual tarefa deverá ser feita primeira, quem a executará e quanto tempo ela levará.

O Scrum não pode se basear em suposições – o que pode acontecer no início de um trabalho complexo, quando o nível de informação é baixo. É fundamental aprender fazendo e depois ir alimentando as informações de volta ao processo.

Questão de estimativas

Finalmente, é interessante saber que estimativas são necessárias, porém o time nunca deve fingir que sabe mais do que realmente sabe.

O Sprint Planning exige certo nível de estimativa, definindo assim o que pode e o que não pode ser feito na Sprint. Porém, não confunda estimativa com compromisso. As estimativas são previsões que têm como base o conhecimento disponível e isso requer confiança, informações oferecidas de maneira livre e que as presunções sejam discutidas com foco em aprender e aprimorar.

Por fim, para planejar uma boa Sprint de acordo com o Scrum Guide, você não pode esquecer que o foco é criar um plano “somente o suficiente” para a próxima Sprint.

Lembre-se de que o plano não deve se tornar um fardo para o time Scrum, mas sim que ele traga resultados valiosos, motivação e sucesso.

Tio Adriano também indica a leitura de: As diferenças entre Scrum e Kanban

Enfim, sugiro que leia outros artigos relacionados que vez ou outra publico também no blog da PMG. E deixe seu comentário sobre o assunto se tiver dúvidas sobre o Scrum.