A reunião de Sprint Planning efetiva

Neste artigo pretendo orientar como fazer uma reunião de sprint planning efetiva.

No início de cada Sprint, a equipe Scrum e o Product Owner negociam o escopo do Sprint em uma reunião com tempo limitado para discutir e concordar com o backlog da Sprint, mas como realizar uma Sprint Planning efetiva?

O Product Owner quer que a funcionalidade seja implementada adequadamente e que seja investido o dinheiro do cliente com sabedoria no desenvolvimento, a equipe quer uma missão que consiga cumprir, e claro,  todo mundo quer que a reunião de Sprint Planning termine na hora!

Sprint Planning template

Vou deixar aqui pra você um template de agenda da Sprint Planning, para que seu planejamento de sprint seja bem-sucedido. DOWNLOAD AQUI

A finalidade da Reunião de Planejamento da Sprint (Sprint Planning) é que o Product Owner e a equipe negociem o que deve ser realizado durante a Sprint, ou, como prefiro chamar, o contrato de Sprint.

Embora valorizemos as interações do cliente em relação aos contratos formais, os contratos ainda podem ser úteis e eu gosto de falar sobre um “contrato de Sprint“.

É simplesmente um acordo entre o Product Owner, que concorda em não mudar o combinado antes do final do Sprint, e a equipe, que se compromete a entregar um conjunto definido de funcionalidades até aquele momento.

Parâmetros Básicos do Contrato de Sprint

Um dos segredos mais bem guardados do Scrum é que um projeto consiste em uma série de mini-projetos de tempo fixo, qualidade fixa e escopo fixo, onde cada mini-projeto tem um teto de custo.

Sendo assim basta somar os resultados de todos os mini-projetos juntos e você tem o valor do seu lançamento.

Como o comprimento do Sprint, o tamanho da equipe e a definição do feito são definidos e fixados para a duração do sprint, apenas o escopo pode variar e, mesmo aqui, a equipe se esforça para definir e cumprir o compromisso.

Da mesma forma o custo depende principalmente das horas trabalhadas, o limite superior é conhecido, mas desde que as coisas acontecem.

Bem como ser chamado para ajudar outro projeto ou a visita de um médico inesperado.

Nestes casos o limite raramente é alcançado. Então você tem um teto de custo.

Enquanto a qualidade é expressa através da definição de feito e só deve mudar ocasionalmente. Como todos os parâmetros são fixos para a duração do Sprint, a única coisa a se concordar é o escopo.

Embora não seja um parâmetro do contrato, a velocidade esperada ajuda a definir a expectativa de quanto pode ser realizado dentro da Sprint.

Permanecendo dentro do time-box

O Scrum Master modera a reunião de Sprint planning, mas o Product Owner vem com a agenda, afinal ele quer que a funcionalidade seja entregue e que o projeto geral esteja no caminho certo.

Independentemente da duração do sprint ou do tamanho da sua equipe, a preparação é a chave para terminar a tempo.

Se você está despreparado, a reunião pode realmente se arrastar!

Antes de começar, a equipe de implementação deve ter visto, entendido e avaliado as histórias – As histórias devem ser pequenas o suficiente para serem implementadas em uma sprint – Os critérios de aceitação deveriam ter sido definidos.

Isso aumenta muito suas chances de o Product Owner aceitar a implementação ja na primeira tentativa.

A equipe deve saber quanta capacidade eles têm disponível. Isto é: as férias, treinamentos, eventos da empresa e outros compromissos devem ser conhecidos e contabilizados antes do início da sprint.

Alguns eventos são imprevisíveis, caso em que você apenas faz uma estimativa razoável de quanto vai consumir, concorda com as prioridades do Product Owner e aceita algumas histórias como “condicionais” – aquelas que você fará se tiver tempo.

Uma reunião de planejamento simples da sprint

Eu usei essa estrutura em vários contextos, incluindo um caso em que o Product Owner  pagou pela equipe por hora e outro com equipes distribuídas em dois ambientes (sites) diferentes.

O quanto você precisa ser formal dependerá de muitas coisas, incluindo o tamanho do projeto, quão bem o projeto está indo, a relação comercial entre o proprietário do produto e a equipe, como as partes cooperam, etc.

Quanto mais desafiador o projeto, mais você precisa pontilhar você e cruzar seu t.

Revise os parâmetros básicos – Data de início e término, hora e local da reunião de revisão do sprint, disponibilidade da equipe e definição de pronto;

Apresentar e discutir cada história – Uma caixa de tempo para cada um pode ser útil para manter toda a reunião no caminho certo, manter uma reserva no final desta seção para histórias difíceis geralmente torna mais fácil seguir em frente se a discussão estiver ficando presa em uma história;

Comprometa-se com as histórias – Percorra a lista, uma de cada vez e por ordem de prioridade, faça com que a equipe se comprometa com cada uma até que ninguém se comprometa mais;

Realize o Acordo – Confirme a lista de histórias confirmadas com o Product Owner.

Como Scrum Master, achei útil confirmar o contrato da Sprint com um e-mail para o Product Owner, nele enviei:

1. Uma imagem do quadro de tarefas,
2. Um pdf da planilha,
3. Um dump de tela da página wiki,
4. Ou até mesmo o próprio chamado na ferramenta que utilizamos (com os anexos nele)

O que pode ser uma maneira eficaz de capturar o contrato.

Todos ficam sabendo exatamente sobre o que deve ser feito e tanto o Product Owner quanto a equipe têm uma base sólida para examinar o sucesso da sprint e o estado geral do projeto na revisão do sprint.

Conclusão

Em suma, não é porque priorizamos software funcionando em detrimento de documentação que você não “pode” ou “deve” parar de trabalhar em seus documentos.

E você pode utilizar esse template numa reunião de Sprint Planning e conseguir “fechar” o contrato com sua equipe e seu Product Owner de uma forma simples e transparente.

Em breve enviarei mais notícias das minhas jornadas ágeis e conforme for aprendendo eu acabo compartilhando com você. Um grande abraço e até semana que vem.