Reunião de Sprint Planning: Definição, Processo e Dicas Importantes

O kick-off de cada Sprint é o Sprint Planning Meeting. Ele serve para definir a carga de trabalho da equipe Scrum para o próximo Sprint. Como o Sprint Planning Meeting deve ser preparado pelo Product Owner, quem participa, qual é o processo e o que a equipe deve considerar, você vai descobrir neste artigo.

Sprint Planning: Objetivos e Participantes da Reunião

Um Sprint Planning Meeting tem dois objetivos. Após um Sprint Planning bem-sucedido:

• Product Owner e Time de Desenvolvimento estão de acordo sobre o objetivo do Sprint (Outcome)
• e juntos criaram o Sprint Backlog. O Sprint Backlog contém todos os Product Backlog Items que precisam ser implementados no Sprint para alcançar o objetivo do Sprint (Output).

Em alguns casos, Outcome e Output também são resumidos como MVP, Minimum Viable Product.

Quem convida para o Sprint Planning?

O Product Owner convida a equipe de desenvolvimento e o Scrum Master para a sessão de Scrum Planning. Se houver Stakeholders que queiram acompanhar qual será o objetivo do Sprint e quais itens do Backlog serão trabalhados, o Product Owner também os convida.

Preparação da Reunião de Planejamento do Sprint

Para que o Product Owner e a equipe de desenvolvimento alcancem os dois objetivos da reunião de planejamento, algumas condições prévias precisam ser criadas. Os seguintes passos preparatórios são, portanto, essenciais antes do Sprint Planning no Scrum. Se você trabalha como PO ou está se preparando para o papel de Product Owner, pode usar esta checklist ou os pontos listados abaixo.

• O Product Owner definiu um objetivo do sprint (Outcome) e selecionou os Product Backlog Items (PBIs) correspondentes.
• Os PBIs selecionados foram formulados com detalhes suficientes – preferencialmente em colaboração com a equipe de desenvolvimento, por exemplo, durante um Product Backlog Refinement.
• Os PBIs selecionados foram priorizados na ordem em que a equipe de desenvolvimento irá trabalhá-los. As dependências técnicas foram consideradas.
• A equipe possui uma Definition of Done (DoD). Ela fornece um entendimento comum de "quando algo está pronto".
• A capacidade da equipe para o próximo sprint foi determinada, por exemplo, considerando a velocity média dos últimos sprints e eventuais férias planejadas de membros da equipe.

O Fluxo do Sprint Planning

Com o Sprint Planning preparado conforme descrito, você pode começar o processo propriamente dito com sua equipe Scrum. A reunião segue a seguinte agenda do Sprint Planning:

• O Product Owner apresenta o objetivo do sprint e os PBIs correspondentes, respondendo às perguntas de compreensão da equipe. O objetivo do sprint deve ser documentado de forma bem legível no Sprint Backlog para todos os membros da equipe.
• Se os PBIs ainda não foram estimados, vocês devem fazer a estimativa agora. Se a estimativa já ocorreu, sua equipe pode refinar a estimativa após a discussão detalhada sobre a implementação.
• A equipe faz uma previsão para o Product Owner e stakeholders sobre quais PBIs entregará ao final do sprint, de acordo com a DoD elaborada em conjunto. Dessa forma, é formado o Sprint Backlog, onde deve estar documentado a quais PBIs a equipe de desenvolvimento se comprometeu e quais trabalhará opcionalmente.

Naturalmente, no Scrum também existe uma timebox para o Sprint Planning: a duração de um Sprint Planning não deve exceder um dia (Timebox: 8 Stunden).

Distinção entre Sprint Planning 1 e 2

Nossa dica prática: frequentemente, as equipes Scrum distinguem entre Sprint Planning 1 e 2:

• Sprint Planning 1 trata da pergunta: O que queremos abordar no próximo sprint?
• Sprint Planning 2 trata da pergunta: Como queremos abordar?

A timebox dos dois planejamentos, aliás, não se divide em 4 horas cada – em vez disso, o Planning 1 é automaticamente bastante curto após um bom refinement, enquanto a maior parte da timebox é necessária para o Planning 2.

Embora não seja obrigatório, algumas equipes de desenvolvimento no Scrum Sprint Planning 2 quebram os Product Backlog Items em pacotes de trabalho menores (Tasks). Esta segunda parte do Sprint Planning frequentemente acontece sem o Product Owner.

O que mais uma equipe deve considerar no planejamento do sprint?

Uma equipe de desenvolvimento nunca conseguirá trabalhar exclusivamente nos Sprint Backlog Items escolhidos durante um sprint, pois em todo ambiente de trabalho ágil existem interrupções, pequenas emergências e solicitações urgentes de suporte.

Por isso, vale a pena para sua equipe planejar uma espécie de buffer nos sprints, que considere, por exemplo, as seguintes atividades:

• Resolver problemas operacionais, por exemplo, quando um servidor cai
• Corrigir bugs críticos
• Suporte técnico de primeiro ou segundo nível

Esses buffers garantem que o Scrum Sprint Planning produza um backlog que a equipe realmente consegue entregar, sem se frustrar com interrupções. Além disso, nossos estudos mostram que equipes com buffer se tornam mais performantes ao longo do tempo. Isso acontece, entre outros motivos, porque essas equipes alcançam seus objetivos de sprint com mais frequência e, assim, têm mais experiências de sucesso.

Os Resultados do Planejamento do Sprint

Quando você e sua equipe conseguirem marcar os seguintes pontos como concluídos, saberão que o planejamento do sprint foi bem-sucedido e que fizeram tudo certo:

• A equipe Scrum desenvolveu um entendimento comum sobre o que deve ser alcançado no próximo sprint (objetivo do sprint).
• Através da discussão entre a equipe de desenvolvimento, vocês desenvolveram um entendimento comum de como os respectivos PBIs devem ser implementados.
• Vocês criaram um Sprint Backlog bem estruturado, que contém os PBIs na ordem do Product Backlog, possivelmente até após um Task Breakdown incluindo as atividades correspondentes.

O Maior Erro na Reunião de Sprint Planning

Algumas equipes de desenvolvimento insistem em criar o Sprint Backlog perfeito, tentando identificar cada tarefa, por menor que seja, e estimá-la de forma meticulosamente precisa. Isso geralmente acontece quando a gestão ainda não compreendeu completamente a forma de trabalho ágil e exige tais estimativas "exatas".

Como se perde muito tempo com uma estimativa excessivamente precisa na reunião de Sprint Planning, o Scrum Master deve garantir que o objetivo real do planejamento não se perca: selecionar os PBIs certos para o próximo sprint e conversar sobre eles apenas o suficiente para que a equipe se sinta preparada para trabalhar nos itens.

Conclusão sobre a Reunião de Sprint Planning

Uma reunião de Sprint Planning bem-sucedida depende de uma boa preparação, como o Product Backlog Refinement. A reunião de Sprint Planning, por sua vez, fornece a condição para que todos na equipe saibam o que será implementado no próximo sprint e como. Se o sprint deve ser bem-sucedido e a equipe de desenvolvimento deve trabalhar nos PBIs de forma bem-sucedida e sem frustração, a reunião de planejamento no Scrum é absolutamente indispensável.