Sprint Planning de Longa duração? Nunca mais!

Qual foi o record de vocês com relação à duração de uma sprint planning? O meu foi 8hs! Ou seja, uma reunião chata, massante e com estimativas totalmente longe da realidade e com algumas cochiladas no meio. Quem nunca? 😉. Essa semana irei falar melhor sobre essa cerimônia e como consegui contornar essa situação.

Partindo do princípio, temos que ter em mente o que é um sprint planning? Rafael Sabbagh (de novo esse cara?) define em seu livro como:

O Sprint se inicia com a reunião de Sprint Planning, na qual se planeja o trabalho a ser realizado no próprio Sprint.

Ou seja, é o momento em que o time de scrum define o como fazer os Product Backlog Items (PBI ou estória) de mais valor, comprometendo-se em entregá-las naquele ciclo de desenvolvimento.

Nessa reunião, o product owner (PO) fala sobre o que é esperado para aquele PBI e qual retorno de investimento ela representa para o cliente. Então, o time de desenvolvimento passa a analisar e criar as atividades necessárias para possibilitar a sua realização.

Algo muito comum, nas reuniões de planejamento de uma sprint, é a estimativa. Geralmente é utilizado o planning poker (baseada na sequência de Fibbonacci) para medir o esforço necessário que o time acredita que aquela funcionalidade tem, sendo um (pouco esforço) e treze para cima (muito esforço).

Agora vou falar um pouco de uma das minhas primeiras experiências que tive com relação a essa cerimônia. Contextualizando: O time era composto por dez pessoas com perfis de back-end, front-end, designers e testers. Utilizávamos “horas” como unidade de medida e levávamos, em média, duas horas por funcionalidade para definir todas as atividades e estimá-las. Geralmente, uma sprint tinha em torno de quatro a cinco PBIs para serem feitas.

O resultado disso era muito simples: nas últimas funcionalidades, as estimativas divergiam da realidade. Ou seja, algo que levávamos três horas para resolver, estimávamos em uma hora, resultando assim no fracasso da sprint. Em seguida, no próximo ciclo, tínhamos o retrabalho de verificar as estimativas das estórias não entregues e ajustá-las. Terrível, não?

Tendo essa experiência como uma lição aprendida, passei a pesquisar formas de fazer um sprint planning mais rápido e mais preciso. Atualmente faço o seguinte: ao invés de uma reunião de horas de duração, eu faço várias reuniões de, no máximo, uma hora. Ou seja, no inicio do ciclo, o time estima uma PBI apenas. A próxima estória só vai ser estimada apenas quando a PBI anterior tiver sido entregue. E assim vai se repetindo até o final do ciclo.

O principal beneficio disso é que as estimativas divergem muito pouco da realidade, trazendo maturidade para o time. Por ficar menos tempo em reuniões, o time se torna mais produtivo, aumentando a capacidade de entregar em uma sprint. Procuramos trabalhar sempre com PBIs pequenas (no máximo 5 pontos de esforço) e caso passe disso, fatiamos em estórias menores, diminuindo sua complexidade.

Fale com o seu PO para deixar as PBIs mais importantes prontas para serem analisadas, pois uma estória sem detalhamento pode comprometer toda a sprint. Geralmente costumo colocar alguns itens como Definition of Done e Definition of Ready. Falaremos mais sobre em outro post

Portanto, fica claro que um planejamento é muito efetivo no sucesso de um projeto. Mas para isso acontecer é preciso maturidade de todos. Percebo que o time se torna muito mais produtivo quando se tem liberdade para realizar seu trabalho. Uma questão muito importante que destaco é a estimativa em esforço e não em horas, pois quando se estima em horas não temos como trabalhar com os imprevistos, nem responder às mudanças rapidamente (lembra do manifesto ágil? ) e também gera um sentimento de individualidade no time (ex: já fiz o meu trabalho, vocês que se virem). E, para finalizar, ter sempre em mente o significado da palavra “estimativa”: avaliação ou cálculo aproximado de algo.  🙂

Espero que tenham gostado.

Grande abraço.

Mostrando 9 comentários
  • Marcelo Ayres
    Responder

    Curti a ideia de “fatiar” o planejamento. Só fiquei em dúvida como fica o comprometimento do time em relação ao “todo” que será entregue ao final do sprint. Ou seja, dessa forma, o time consegue se comprometer com estória A, B e C já no começo do sprint?

    • Diogo Riker
      Responder

      Valeu Marcelo!

      Vai da maturidade e entrosamento do time. Inicialmente pode ficar um pouco dificil, mas se o time tem visibilidade do seu ritmo, eles conseguem se comprometer sim. A maioria dos times que trabalhei conseguiam se comprometer por conhecer o sistema. Mas é algo na base da experimentação.

      Houve uma discussão na comunidade de agilidade no slack sobre isso e gostei da resposta da Ceci, da caelum: ”
      Meu entendimento da meta é que ela serve para dar uma visão mais clara de como essa sprint influência na vida do usuário da nossa aplicação. Se as histórias já trazem informação o bastante para isso e a visão do todo é compartilhada, a meta fica meio óbvia (e vazia)”

      Consegui responder? 🙂

      • Marcelo Ayres
        Responder

        Obrigado, Diogo! Respondeu sim! 🙂

  • Geyder Ribeiro
    Responder

    Acredito que um time certamente deverá está fielmente comprometido com as entregas para alcançar o sucesso e a maturidade cada vez mais, desta forma o “todo” será garantido no final do ciclo.
    A equipe da qual faço parte, evoluiu bastante a partir do momento que adotamos o pensamento da objetividade, que refletiu positivamente na comunicação do time, sem longas reuniões cansativas, e com certeza “fatiar” o planejamento oferece mais segurança, porque é possível elaborar um planejamento mais seguro e definido, uma vez que o mesmo é acompanhado mais precisamente.

    Parabéns Diogo conteúdo muito bem elaborado e interessante.

  • Responder

    A abordagem é legal e que bom que você teve resultados positivos (que é o que importa) porém não concordo com esta forma pois fiquei com a impressão de que o processo está isolado de outros itens importantes da gestão do projeto, como a gestão de riscos. Você aumenta o risco por diminuir o comprometimento da equipe quanto ao backlog da sprint acordado com o PO, já que teria que aguardar algumas atividades para validar se vão mesmo entregar o comprometido.

    Uma Sprint Planning longa pode representar a falta de maturidade no time, onde entendo como confirmação a sua opção de ‘fatiar’ o planejamento devido também à falta de confiança/maturidade nas estimativas. Também pode representar falta de conhecimento do produto ao qual pretendem entregar ao término do projeto (o que geraria dificuldades nas estimativas).

    Como eu resolveria: Faria algumas sessões de coleta de riscos. Coletaria na própria reunião de planejamento uma estimativa de 3 pontos das atividades selecionadas e faria um monte carlo considerando apenas as atividades da sprint e suas dependências. Você teria uma visão melhor (e estatística) o quanto vocês tem chance de entregar naquelas estimativas considerando suas dependências e os cenários pessimistas e otimistas. O cálculo funciona também para story points.

    Se o resultado demonstrasse uma incerteza muito grande, você teria informações para revisar estas estimativas ainda no inicio do projeto.

    Outra forma que poderia resolver é realizar 1 ou 2 spikes para validar o tempo de desenvolvimento, considerando que as incertezas estão vindo de alguma nova tecnologia ou produto que não trabalharam antes.

    Abraços!

    • Jana Pereira
      Responder

      Muito legal suas considerações, Alexandre, são boas estratégias atuando com medidas.

      Não sei se concordo sobre isolamento da gestão de riscos, vejo que essas reuniões menores auxiliam para alimentar e monitorar o plano de risco, talvez o post tenha deixado essa lacuna. Também acredito que as reuniões menores são ações para mitigar riscos anteriores.

      Essa prática deve estar alinhada com o PO para evitar o risco que você comentou de comprometimento da sprint.

      Obrigada pelos seus comentários, ainda vamos trocar muitas experiências.

      Abraço!

  • Jorge Torres Coelho
    Responder

    Com todo respeito, ou eu não entendi o que você quis dizer, ou você não está pregando o Scrum oficial (apesar de ter referenciado o Rafael Sabbagh). No máximo, está fazendo ágil de alguma forma.

    O que não entendi foi você fazer “várias reuniões de uma hora”, sendo que na Planning bastava estimar um PBI. Como se você estivesse diluindo a planning no curso da sprint?

    O que se faz é o grooming antes de iniciar a planning (no decorrer da sprint anterior). O grooming é um refinamento das tarefas, para que quando chegasse na planning não gastasse tanto tempo assim.

    • Diogo Riker
      Responder

      Oi Jorge? Td bem? 🙂

      Como você deve saber, scrum é um framework, ou seja, uma estrutura básica onde você pode adaptá-la de acordo com o seu contexto, respeitando as suas cerimônias. Com relação a sua pergunta, foi exatamente isso que você entendeu.

      A ideia é conseguir diluir o planning durante a sprint sim. Concordo com o Grooming. Mas, não costumo utilizá-lo para detalhar as tarefas. O propósito do refinamento é deixar a User Story preparada para ser puxada na próxima sprint e isso não quer dizer definir as suas tarefas. Utilizo o grooming para responder os “porquês” e deixar o entendimento dela claro para o time.

      Não experimentei ainda em utiliza-lo para definir as tarefas. Atualmente acredito que as tarefas são emergentes, ou seja, surgem de acordo com a necessidade. Mas isso é assunto pra outra conversa.

      Um grande abraço e valeu pelo comentário!

      🙂

Deixe um Comentário

Comece a digitar e pressione Enter para pesquisar

Slip-de-crawford