Sprint Planning

Se você leu o post sobre Ciclos Scrum de Discovery e Delivery, sabe que planejar uma Iteração (Sprint) inicia pelo menos duas semanas antes, quando é selecionado um possível Sprint Backlog que será desenvolvido pelo PO (Product Owner), com participação do UX (User Experience), SEO (Search Engine Optimization), Tester ou SQA (System Quality Assurance), usuários, convidados e referências da equipe técnica.

Aqui, focarei apenas na timebox de Planning, quando pressupomos que podemos iniciar o ciclo de Delivery, quando estimaremos frente as definições apresentadas pelo PO e pactuaremos o que é possível trabalhar e entregar dentro do tempo de uma Sprint (nós fazemos Sprints de 2 ou 3 semanas). Quero compartilhar aprendizados e dicas para que o Planning não seja “apenas mais uma reunião”, mas que cumpra seu papel.

Sprint Planning

A nossa experiência mostra que uma boa reunião de Planning é para ser produtiva, eficiente, mas não precisa ser tensa ou chata, o melhor turno é o da manhã, com todos de buffer vazio, com frequência organizamos um café antes, entre aqueles que querem chegar um pouco mais cedo e descontrair, pois depois é trabalho focado, no geral temos:

1. Os primeiros minutos são alinhamento, datas, o que foi e para onde vamos;
2. Em seguida, calendário, cálculo de velocidade e DoD (Definition of Done);
3. Apresentação e estimativas, podendo ser na totalidade ou em blocos afins;
4. Vou transcrevendo e subtotalizando, puxando setas, alertas, explicitando;
5. Sempre que necessário ou no fim, análise geral de ocupação, P&D, Pair, …;
6. Revisão e debate até fechar pacto de trabalho para o sucesso da Sprint.

Durante a apresentação a ser feita pelo PO, a participação do UX é fundamental, pois o pleno entendimento de cada detalhe e variantes do layout e arte desenvolvidos é crítico para que as estimativas sejam o mais realistas possível. Se PO e UX não tiverem todas ou a maior parte das respostas, o volume de dúvidas e debates podem dispersar e eventualmente inviabilizar as estimativas de parte ou do todo das histórias apresentadas.

O manual diz que Sprint Planning demandam 4 Horas, separadas em 2 Horas para a apresentação do QUE precisa ser feito e qual o valor caso a caso, seguidos de até mais 2 Horas no debate para estimativas do COMO será feito, entretanto nós usamos uma variação, pois as histórias são apresentadas em pequenos grupos corelacionados, seguidos de debate e estimativa, evitando delay com repetição de perguntas ou esquecimento de respostas.

Na prática, se após algum tempo de Planning sentimos que existem mais dúvidas que entendimento, que o Discovery estava muito frágil e que não há como estimar as histórias, eu transformo aquela reunião em uma reunião de DISCOVERY, fechamos as pontas e fazemos o PLANNING na sequência ou na manhã do dia seguinte, isto evita frustrações e estabelemos um passo de cada vez, mitigando o fato de que não estávamos preparados.

Um aspecto fundamental, o Sprint Planning é Visual

Se não houver uma parede forrada de fórmica branca ou um grande quadro branco, não tem problema, use postits e folhas de flipchart colados diretamente na parede que houver, pois é lá que eu transcrevo TUDO o que é debatido, decidido e todos os números, estimados por papel, normalmente [Java] [FrontEnd] [tester], de forma visual construo uma única visão do todo e partes, destacando gargalos e oportunidades, um pacto em tempo real;

Quem olha para o quadro, verá nele absolutamente tudo o que foi tratado, com seus detalhes, pois acredito que é útil todo momento, quando voltamos a algum ítem já discutido ou quando traço uma linha relacionando diferentes ítens ou observações. Também, sempre que temos a mão, colamos o desenho de interface, com as telas ou blocos que construiremos, assim tentamos que nada passe desapercebido e que o sucesso de cada parte envolve as demais.

Como podemos ver nas fotos acima, a maioria das User Story (ou demandas) acabam gerando várias linhas com as tarefas técnicas necessárias para sua construção, como scripts de banco, serviços, frontend, …, dependendo do volume de Histórias e Tarefas pertinentes, uma das formas de montar o kanban é criando uma linha para cada História ou grupo delas, facilitando a visualização do fluxo de cada uma.

Sugestão final, tenha sempre uma câmera de qualidade a mão, não importa o tamanho, mas sempre fotografe suas reuniões, cada parte do quadro, coloque em um repositório, deixe acessível a todos … as vezes quebra o galho.

Boa sorte! Comenta ai se sua experiência aponta outras soluções ou se algo não ficou claro, sempre é difícil ser assertivo em uma lauda, sobre um assunto tão rico quanto uma timeboxe … mas a gente tenta  \o/

13 comentários sobre “Sprint Planning

    • Inicialmente estimávamos em pontos, mas com o tempo não percebemos valor nisto, pois só gerava tentativas de conversões para horas. Somos equipes internas que atendem áreas de negócios próprias, com um ano de experiência em agilidade (Scrum), logo, ainda com muito a aprender … abandonamos as estimativas por postos e usamos a experiência da equipe para estimar diretamente em horas.

      No início do Planning, calculo para todos a velocidade, em horas, descontadas horas de feriadões, ausências programadas, férias e horas administrativas … massa esta utilizada no cruzamento com as estimativas em horas para entendimento do que é possível nos comprometermos.

  1. Interessante, e como é tratado o comprometimento do time em relação as estórias, por exemplo, se o time se compromete com um numero ‘X’ de estórias e durante o sprint eles percebem que não vão conseguir atender ao que foi comprometido, é utilizado horas extras para atingir o objetivo?

    • Desde que adotamos Agile NÃO usamos mais horas extras para obter resultados, o segredo é praticar os pilares do Scrum na Daily, ou seja, cada qual deve ser transparente e realista, pedindo ajuda e oferecendo sempre que possível, de resto cabe ao P.O. tomar as decisões. Venho dizendo que se temos 2 ou 3 dailys sem nenhuma decisão “importante” … é porque a daily ou o Kanban não estão refletindo a realidade 🙂

      • Inclusive, a mesma equipe de desenvolvimento também faz manutenção, por isto calculo em torno de 50 a 60% do tempo para projeto e o restante para manutenção (postit’s extras), as dailys é que vão dando os caminhos e o P.O. as vezes traz uma U.S. de volta para o backlog ou a garante para o próximo Sprint. Não tem uma receita de bolo, é bom-senso !

  2. Mas o exemplo que dei anteriormente ocorre com alguma frequência com vocês, digo de os times errarem as estimativas ou isso é uma exceção?

    • Acontece, em torno de 30 a 40% das U.S. mas assim como erra-se para cima, erra-se para baixo, como temos o % de horas para manutenção, quando há impacto, a decisão normalmente é tentar filtrar um pouco mais os Extras … via de regra dá certo.

      • A arte do Agile não é acertar sempre, mas antecipar a percepção de desvio e corrigir, normalmente se corrige rapidao e facilmente, mas as vezes exige um plano de ação mais intenso … é ai que podemos acabar comprometendo uma U.S. que pode ficar para o próximo Sprint ou voltar para o backlog …

  3. Trabalho com métodos ágeis já a algum tempo e algumas vezes tive problemas com o PO por causa dos prazos da Release, mas foi bom saber a maneira como vocês trabalham e como tentam resolver seus problemas, obrigado.

  4. Pingback: Planning fácil e burocrático é mal sinal | Jorge Horácio "Kotick" Audy

  5. Pingback: Um ano e meio de blog – Obrigado galera! | Jorge Horácio "Kotick" Audy

    • Báh, é um post de 2012, o reli agora e ainda representa a essência de um bom sprint planning \o/ Qualquer dúvida, pergunta aí que estou a disposição. Um tópico que não falava naquela época é a necessidade de explicitar qual a previsão de tempo ou % a ser dedicado em reserva técnica, relativo a sustentação do que já temos em produção, comprometimento dos integrantes do time com outros projetos, etc. É muito importante para que durante o sprint possam monitorar e identificar se o tempo de RT pode ou não estar pondo em risco o sprint backlog ou mesmo permitirá antecipar algo do próximo sprint ou prioridade dada pelo PO.
      [ ]

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s