Sprint Planning, dicas para ter uma fantástica reunião

Nas últimas semanas, recebi muitos comentários dos meus seguidores sobre o que gostariam de ler nas próximas semanas. Um dos tópicos foi: Como Ter Um Sprint Planning efetivo.

Para alguns de vocês, este pode ser um tópico básico, se este for o caso, sinta-se à vontade para o ignorar.

Sprint Planning Efetivo

Qualquer trabalho que deva ser executado no Sprint é planeado no Sprint Planning. O planeamento reúne toda a equipa Scrum e é criado através do trabalho colaborativo. O sprint planning tem o máximo de duração de oito horas para um sprint de um mês.

Em Scrum, as equipas planeiam escolhendo Stories do product backlog. Depois, comprometem-se com um conjunto para executar num próximo sprint.

Como mencionado, cada equipa planeia o próximo sprint numa reunião time-boxed (como em muitos Artefactos Scrum ).  É da responsabilidade do Scrum Master certificar-se que o evento se realiza e que os participantes compreendem a razão do mesmo. O Scrum Master vai ensinar a equipa a ficar dentro da time box.

No final da reunião (resultado) a equipa terá:

• O sprint backlog, composto pelas stories da equipa para o próximo sprint. Num cenário ótimo, estas stories terão critérios de aceitação.
• As Metas Sprint
• Um acordo com a equipa para fazer o que é possível para atingir as metas. A palavra compromisso foi removida do último Guia Scrum. Do meu ponto de vista pessoal, esta foi uma boa decisão.

O objetivo da Reunião de Sprint Planning é organizar o trabalho e definir um âmbito realista para o próximo sprint.

As equipas concordam num número de stories que podem retirar do backlog. Claro, que têm de ter em consideração a disponibilidade dos membros da equipa. Depois de concordar naquilo que vão tirar do backlog, definem as Metas, juntamente com o Product Owner.

Por vezes, é necessário fazer alguns ajustamentos para atingir um propósito mais amplo.

A capacidade da equipa é baseada na complexidade da story, tamanho e dependências doutras stories e doutras equipas. Todos tentamos conseguir equipas que tenham responsabilidade do início ao fim. Infelizmente, a realidade é um pouco diferente, e é bastante comum ter várias dependências em relação a outras equipas.

Pré-requisitos para uma Reunião de Sprint Planning Efetiva

Antes da reunião, o Product owner deve preparar um rascunho das próximas Metas Sprint. Geralmente, parte desta tarefa é feita na sessão de Grooming.

Outra parte importante é estar alinhado com outros Product Owners, no caso de a equipa ter dependências com outras. É muito frustrante para membros da equipa quando os Product Owners chegam a uma reunião e podem dar trabalho que não pode ser realizado devido a dependências externas.

Não só é o Product Owner que tem de fazer o seu trabalho de casa, os membros da equipa também têm de estar preparados. É comum ter estas tarefas de pesquisa (spikes) que têm de ser feitas antes do Sprint Planning. Estas tarefas geralmente respondem a questões relacionadas com arquiteturas ou implementações futuras.

Diretrizes para um Sprint Planning Efetivo

Entre os participantes para o Sprint Planning incluem-se:

• O Product Owner
• O Scrum Master,  que age como um facilitador
• Todos os outros membros da equipa

Agenda

Um exemplo da agenda do Sprint Planning:

• A equipa determina a velocidade disponível para o Sprint
• Se usar #NoEstimates, a equipa determina o número de stories que atingiram no passado (por sprint) e quantas stories podem atingir, tendo em conta a sua capacidade
• O Product Owner apresenta as metas Sprint; a equipa discute e concorda com os objetivos
• Pessoalmente, acho o último tópico uma abordagem um pouco top-down. Prefiro perguntar à equipa sobre a Meta, com a orientação certa do Product Owner, claro
• A equipa discute cada story uma a uma. Para cada story a equipa:
• Dimensiona cada story em pontos de story e divide-os se necessário
• Se usar #NoEstimates quebra a story até a equipa estar confortável em entregar a story até dois dias
• Elabora critérios de aceitação através da conversação
• Tendo em conta o tamanho e valor/tempo/risco, o PO pode estabelecer um novo ranking para as stories
• Algumas equipas dividem as stories em tarefas, estimadas em horas
• O planeamento para quando a equipa já não tem mais pontos
• A equipa e o PO negoceiam e finalizam as stories selecionadas
• Todos se comprometem com as metas Sprint 

Reunião

Geralmente, o Product Owner começa a reunião revendo as metas Sprint propostas. Durante a reunião, a equipa discute a implementação e as diferentes opções. Nesta reunião, o Product Owner é o responsável por definir o quê; a equipa define como e quanto.

Durante a reunião, a equipa elabora sobre um critério de aceitação (juntamente com o Product Owner) e estima o esforço para completar para story.

Tendo em conta a sua velocidade, a equipa seleciona as stories dos candidatos. Muitas equipas dividem cada story em tarefas e estimam em horas para confirmar que têm a capacidade e competências para os completar.

Assim que a capacidade da equipa tiver sido estabelecida, a equipa volta a sua atenção para compreender e concordar sobre uma ou mais metas sprint.

O product owner e a equipa concordam numa lista final de stories que será atingida. Os Sprint Goals são depois revisitados e reafirmado e a equipa chega a um consenso relativamente a uma lista final de stories a serem atingidas. A equipa inteira compromete-se com os Sprint Goals e o âmbito do trabalho permanece fixo durante a duração do sprint.

É muito importante mencionar que, na maioria das vezes, as equipas estão com confiança a mais. Tendem a escolher mais stories do que aquelas que foram capazes de atingir em sprints anteriores. Como o Scrum Master os desafia, geralmente, não o vão fazer, isto conduz a muita frustração e desilusão.

Espero que tenha gostado do post de hoje, por favor faça o share com os seus colegas.