A Arte da Priorização

  •  
  •  
  •  
  •  

E aí galera.

Hoje vou falar um pouco sobre uma prática muito comum dentro do Scrum e que facilita bastante o trabalho do time: Backlog Grooming.

Já aconteceu com vocês aquele momento em que, na hora do planejamento, diversos itens são estimados com um esforço gigantesco por causa de dúvidas ou não entendimento daquela funcionalidade? Ou então um item extra aparecer nos 45 do segundo tempo, fugindo totalmente do objetivo da sprint? Bom, se você já sofreu com isso, é sinal de que você já foi vítima da terrível dupla dinâmica: O Horrível Product Owner (PO) e O Péssimo Scrum Master (SM).

O Horrível Product Owner e o Péssimo Scrum Master

O Horrível Product Owner e o Péssimo Scrum Master

Nessas horas, é importante que todos conheçam uma ação chamada Backlog Grooming ou refinamento do backlog. Um conceito muito simples que sugere que o backlog de um projeto seja constantemente revisado e repriorizado, variando de acordo com as entregas e o retorno de investimento (ROI). Ken Schwaber e Jeff Sutherland, autores do Guia do Scrum, definem isso da seguinte forma:

O refinamento do Backlog do Produto é a ação de adicionar detalhes, estimativas e ordem aos itens no Backlog do Produto.

Como vocês podem perceber, é algo que conta com a participação de todos os papéis do scrum, mas a responsabilidade de manter o backlog priorizado e atualizado é do PO, pois é ele que entende melhor sobre o ROI para o cliente.

Os itens que estão no topo do backlog de um produto devem estar bem claro para que o time de desenvolvimento tenha condições de estimar o esforço que investirá para desenvolver. Caso isso não aconteça, teremos como consequência muitas dúvidas e grande dificuldade em fazer com que a estimativa seja a mais próxima possível da realidade.

Se o time todo não pode participar, recomenda-se que pelo menos 1 ou 2 pessoas do time de desenvolvimento e também o SM estejam presentes nessa atividade, pois dessa forma fica muito mais fácil alinhar as expectativas sobre o que vai ser trabalhado e, consequentemente, entregue.

E quando isso deve acontecer? Bom, não tem um momento certo. Já trabalhei com times que faziam antes do sprint planning e outros que fazem no decorrer da sprint. Na minha opinião, acho interessante que aconteça no decorrer da sprint, pois é algo que não consome tanto tempo (basta se organizar para isso) e também não sobrecarrega o time de desenvolvimento antes de começar o planejamento. Porém, coloco aqui um contra-ponto. Ao realizar no decorrer da sprint, haverá uma mudança de contexto e foco por parte do time, afetando diretamente a sprint atual, portanto, procure conhecer o seu time para saber em que momento realizar isso.

Mas Diogo, se é responsabilidade do PO, por que você falou que a culpa também é do Scrum Master no início do post? Então, como já vimos aqui, uma das funções dele é ajudar no gereciamento do backlog. Caso o PO não tenha iniciativa de fazer isso, ou envolver o restante do time de Scrum, o SM deve instrui-lo a fazer isso da forma da melhor forma possível.

Sendo assim, fica claro o por que do refinamento ser uma ação muito importante. Todos devem entender que o Backlog de um produto é um documento vivo, dinâmico e colaborativo. Gosto de pensar que este, é como se fosse um bar e que para fazer com que seja bem frequentado, é preciso mante-lo em ordem, arrumado e com o estoque sempre disponível para seus clientes. Ah, e ter cerveja de qualidade é muito importante também!

Existem algumas técnicas bem interessantes de como fazer esse refinamento e iremos falar mais sobre elas em outros posts. Já está no nosso backlog ;).

Abraço.

Showing 3 comments
  • Claudio Fernando Maciel
    Responder

    Excelente artigo! Promover uma mudança de postura do time para que a famosa caça às bruxas deixe de ser praticada. Afinal de contas, todos são parte de um mesmo projeto onde as vitórias são comemoradas, mas também os fracassos são responsabilidade de todos e o mais importante de tudo, muitas vezes um mal necessário para formar um time amadurecido.

    • Diogo Riker
      Responder

      É verdade, Claudio!

      É muito importante que o time entenda que todos estão no mesmo barco. Todos os envolvidos, mesmo que não estejam presentes no local (como clientes que ficam remotos, por exemplo), fazem parte do conceito de TIME.

      Comemorar as vitórias é muito importante para “buildar” o time, aumentando o entrosamento e, o mais importante de todos, tirar lições aprendidas dos fracassos é essencial para a evolução tanto do time, como do individuo.

      Um abraço. 🙂

      • Jana Pereira
        Responder

        Uma das coisas que acho legal do scrum é não retratar algum membro do TIME como o salvador, o responsável. A evolução, os resultados dependem exclusivamente dos envolvidos e da forma como eles estão dispostos a interagir em todas as fases do projeto, altos e baixos. Fico pensando se a realidade fora dos projetos, no mundo real, nas atividades do cotidiano fossem compreendidas com essa mesma vontade de trabalho em time, o que seria diferente no mundo?

Leave a Comment