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  ATUALIZADO VERSÃO 2.0

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.

6 Comments

  • Rodrigo quando se tem vários sistemas e que a empresa precisa e quer modernizar, reescrevendo todo
    O sistema do zero, mas o software atual precisa ser mantido, o que você sugere que faça? Seria prudente ter uma equipe para cuidar do sistema atual e outra exclusiva para fazer o novo sistema?

    Fabiano Moura janeiro 27, 2022
    • Fabiano, bom dia.

      O recomendado é manter uma pequena equipe que suporte os sistemas de legado, deixando claro que os sistemas não terão mais evolução, essa informação é de suma importância, todos os stakeholders devem saber que os sistemas atuais NÃO PODEM MAIS EVOLUIR e os itens de evoução entram no backlog da modernização.

      O time de modernização deve introduzir as equipes de produtos anteriores para construção e modernização do novo sistema já considerando as evoluções, mas as entregas de release devem ser feitas através de um roadmap muito bem elaborado com versões de partes dos sistemas.

      Sem que todos esteja de acordo com estes objetivos o projeto será um fracasso.

      Coimbra janeiro 28, 2022
  • […] reunião de planejamento de iteração (Sprint Planning) define o cenário e deve ser executada como um diálogo […]

  • […] Espero que todos estejam familiarizados com a terminologia “definition of done” (DoD), ou “done-ness”, do ponto de vista dos métodos ágeis. É uma frase comum e incrivelmente importante para a saúde e maturidade da equipe ágil. É essencialmente um critério de saída, se você preferir, para o trabalho de sprint das equipes. […]

  • […] ou iniciativas não relacionadas. – Quando estamos ordenando o Product Backlog e fazendo o Sprint Planning, considere tanto a coesão do trabalho quanto a iniciativa de prioridade máxima (singular).- […]

  • […] o PO não afete os compromissos de um Scrum durante o planejamento do sprint (avaliando o progresso por meio de revisões e retrospectivas do sprint), ele usa o chapéu de […]

Leave a comment

Your email address will not be published.

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

Pular para a barra de ferramentas