Como priorizo o backlog do meu time?

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Este post não tem tags.

Compartilhe:

Muitos times têm dificuldade de priorizar quais as próximas coisas devem ser feitas do que está no backlog. Uma forma simples de priorizar é utilizando o Retorno sobre Investimento (Return on Investment – RoI). Podemos simplificar o RoI como uma equação onde o Retorno esperado é dividido pelo investimento que temos que fazer para construir algo.

Quando conseguimos utilizar dinheiro para medir o RoI, as coisas ficam bem fáceis, todavia nem sempre conseguimos fazer tal coisa. Como então podemos priorizar o nosso backlog? Neste artigo veremos duas técnicas colaborativas que podemos utilizar para encontrar o Retorno e o Investimento.

Estimando o Retorno com Buy a Feature – Priorização de Backlog

Buy a Feature (Compre uma funcionalidade) é uma técnica criada por Luke Hohmann e apresentada em seu livro Innovation Games: Creating Breakthrough Products Through Collaborative Play (2006). Para utilizá-la é necessário que já tenhamos um backlog mínimo definido. Idealmente esse backlog não é muito extenso. Quanto maior, mais difícil será utilizar a técnica e é provável que tenhamos ido longe demais na definição de escopo.

Um backlog representado por cinco retângulos empilhados um sobre o outro. Cada um com o seu “nome”: Item A, Item B, Item C, Item D e Item E.
Backlog inicial não priorizado

Como exemplo, vamos imaginar que tenhamos o seguinte backlog composto por os itens A, B, C, D e E. Imaginemos também que há três stakeholders nessa reunião. A dinâmica é a seguinte:

  1. Reúne-se um grupo de stakeholders, pessoas interessadas no produto / serviço que estamos construindo. Se possível, os consumidores finais.
  2. Apresentamos os itens de valor descritos no backlog.
  3. Cada pessoa receberá 100 moedas. Você pode utilizar dinheiro de jogos, fichas de poker ou apenas post-its indicando o valor.
  4. As pessoas devem “comprar” os itens de backlog. Para tal, elas distribuirão as 100 moedas conforme elas desejarem.
Um backlog com cinco itens e com os valores de cada item. O Item A recebeu a seguinte quantidade em moedas: 15, 20 e 10. O Item B recebeu a seguinte quantidade em moedas: 15, 20 e 50. O Item C recebeu a seguinte quantidade em moedas: 25, 20 e 30. O Item D recebeu a seguinte quantidade em moedas: 20 e 5. O Item E recebeu a seguinte quantidade em moedas: 40, 20 e 10.
Backlog após os stakeholders informarem o quanto eles “pagaram” por cada item.

No final, para cada item do backlog, somamos quantas moedas ele ganhou. O RETORNO é o somatório de moedas que o item recebeu. Aqui cabe uma dica importante. Caso existam itens que não receberam moedas, pense se não vale a pena descartá-los, afinal, os stakeholders não viram valor neles. Ordene o Backlog pelo retorno estimado.

O mesmo backlog apresentado nas imagens anteriores. Só que agora ele está empilhado de acordo com o somatório recebido durante a dinâmica do Buy a Feature. A ordem é: Item B com 85 moedas (15 + 20 + 50), Item C com 75 moedas (25 + 20 + 30), Item E com 70 moedas (40 + 20 + 10), Item A com 45 moedas (15 + 20 + 10) e Item D com 25 moedas (20 + 5).
Backlog priorizado pelo Retorno Estimado após o somatório das “moedas” distribuídas durante o Buy a Feature.

Vantagens dessa técnica:

  • é colaborativa;
  • utiliza a inteligência coletiva do grupo;
  • permite que todos opinem;
  • é rápida;
  • independe de base histórica.

Desvantagens:

  • não é possível avaliar se o resultado obtido foi igual ao esperado;
  • não permite a comparação entre dois ou mais produtos ou serviços;
  • depende do know-how das pessoas que estarão presentes.

Estimando o investimento com Planning Poker

Planning Poker foi uma técnica criada por James Grenning em 2002 e divulgada em seu artigo Planning Poker or How to avoid analysis paralysis while release planning. O seu objetivo primário proporcionar um momento para que as pessoas que irão construir o produto possam conversar sobre como essa construção será feita. Ela é uma dinâmica de facilitação também evita que gastemos horas e horas de discussão para estimar o investimento necessário para construir um item do backlog. Antes de explicarmos o método, vejamos algumas considerações.

Esforço

No Planning Poker o investimento será o esforço necessário para construir um item do backlog. Esse esforço deve levar em consideração três aspectos:

  • Trabalho braçal: Para construir o item não há tanta complexidade, porém será necessário muito esforço manual. Exemplos: Copiar uma série de valores de um arquivo texto desestruturado para uma planilha.
  • Complexidade: Passaremos mais tempo pensando em como construir o item do que de fato construindo. Exemplo: Algoritmos complexos, alteração de esteiras de produção que já estão em funcionamento (sem pará-las).
  • Incerteza: Não sabemos exatamente como construir o item. Haverá alguma pesquisa prévia e algumas hipóteses técnicas serão validadas.

Escala de valores

Os valores que o esforço pode assumir são baseados na série de Fibonacci. Nela, a soma dos valores anteriores é igual ao próximo valor da série. Por exemplo: 1 + 2 = 3; 2 + 3 = 5…

Para Cego ver, uma imagem com os números da sequência de Fibonacci. Nela temos: 1 + 2 = 3. 2 + 3 = 5. 3 + 5 = 8. 5 + 8 = 13. 8 + 13 ≈ 20. 13 + 20 é tipo 40. 20 + 40 é tipo 100.
Formação da Série baseada na Sequência de Fibonacci.

Por que 8+13 ≅ 20 e não = 21? Porque sabemos que depois de certo ponto começamos a ter muitas incertezas e não temos mais precisão na estimativa.

Por que 13 + 20 = 40 e 20 + 40 = 100? Neste caso o esforço é tão alto que a imprecisão se torna igualmente elevada. Itens que recebem tais esforços são tão grandes e com tantas incertezas que representam um risco para construí-los. O melhor é fatiá-los.

Quem participa do Planning poker?

Só pontuará esforço quem participa ativamente da construção. Caso estejamos utilizando os papéis do Scrum, apenas o Time de Desenvolvimento. O Scrum Master facilita o Planning Poker e o Product Owner tira dúvidas, mas nenhum deles pontua.

“Só pontua quem suja a mão de graxa”
(Rodrigo de Toledo)

Setup

  1. O Product Owner apresenta os itens do backlog para o Time de Desenvolvimento. Preferencialmente, após a estimativa de Retorno. A ordem de apresentação é dos mais valiosos para os menos valiosos.
  2. O Time de Desenvolvimento escolhe o item mais fácil de ser construído e atribui o valor 2 para esse item.
  3. A partir daí, o time irá comparativamente definir o esforço dos demais itens tendo o mais simples como base.

Para a próxima etapa, cada membro do Time de Desenvolvimento terá um baralho com as cartas indicando a escala de valores. Esses baralhos podem ser comprados, fabricados e até mesmo recebido em eventos sobre agilidade. Há também Apps que podem ser encontradas nas lojas de aplicativos como Google Play e App Store.

Por que estimar com o valor 2 e não o valor 1? Durante a vida do produto ou serviço é possível que encontremos um item que seja mais simples do que aquele que inicialmente pontuamos. Nesses casos, utilizaremos o valor 1.

Evite utilizar valores quebrados como ½ , pois só complicam as contas e não apresentam uma informação valiosa.

Execução do Planning Poker

Olharmos os itens do backlog. Para cada um:

O Product Owner lê o item.

  1. Cada membro do Time de Desenvolvimento deve estimar o esforço que acredita que aquele item exigirá para ser construído levando em consideração os três aspectos (trabalho braçal, complexidade e incerteza) e o item base. Com o intuito de evitar que as estimativas de membros mais experientes interfiram na estimativa dos menos experientes, ninguém deve mostrar o esforço escolhido para ninguém.
  2. O Scrum Master pede então para que as pessoas “joguem” (apresentem as suas estimativas).
  3. Caso todos tenham dado o mesmo valor, esse é o esforço para executar o item. Podemos ir para o próximo e repetir toda a dinâmica.

Caso os valores não sejam iguais

Nesses casos temos que ir para o desempate. Imagine que para o Item A, os membros do time deram as seguintes estimativas: Beto 2 pontos, Ana 5 pontos, João 13 pontos, Maria 5 pontos e Miguel 8 pontos.

Uma imagem em que aparecem cinco avatares e cada um deles dando sua estimativa conforme descrito no parágrafo anterior. As cartas possuem uma cor para ajudar a diferenciá-las. O esforço 2 dado pelo Beto tem a cor verde, O esforço 5 dado por Ana e Maria é amarelo, O esforço 8 dado pelo Miguel é laranja e o esforço 13 dado pelo João é vermelho.
Exemplo de uma jogada de planning poker em que há divergência de esforço estimado.

Quem deu os valores extremos, mais baixo e mais alto, devem explicar por que deram esses valores. Por que isso? É possível que a pessoa que deu o valor mais baixo não esteja consciente da complexidade, incerteza ou esforço braçal para concretizar o item de backlog. Por outro lado, a pessoa que deu a estimativa mais baixa pode conhecer mais sobre o assunto e esse será o momento dela explicar o caminho das pedras para os outros membros do Time de Desenvolvimento.

Uma vez apresentada as explicações. Todos os membros do time escolhem sua estimativa e jogam novamente. Esse processo se repete até que as estimativas convirjam para um único valor.

Não seja cri, cri (perfeccionista)

“Ninguém ganha dinheiro estimando.”
Rodrigo de Toledo

Digamos que ao jogar o Planning poker para o item C, esse time imaginário tenha dado as seguintes estimativas: Beto 2 pontos, Ana 2 pontos, João 3 pontos, Maria 3 pontos e Miguel 3 pontos. Por regra há divergência e deveríamos jogar novamente. Todavia a distância é muito pequena e nem sempre valerá a pena fazer uma ampla discussão sobre o item. Pergunte se os que deram 2 pontos aceitariam trocar para 3 e siga para o próximo item do backlog.

Concluindo o Planning Poker

Ao final do Planning Poker teremos o Investimento (esforço necessário para construir cada item).

O backlog com as estimativas de retorno e investimento. Permanecem retângulos empilhados na seguinte ordem: Item B (Retorno = 85, Investimento 13), Item C (Retorno 75, Investimento 3), Item E (Retorno 70, Investimento 5), Item A (Retorno 45, Investimento 5) e Item D (Retorno 25, Investimento 2).
Backlog com o Retorno (em azul, à esquerda) e o Investimento (colorido, à direita).

Quando fazer?

A estimativa de valor poderá ser feita sem a participação do time, desde que o Product Owner consiga a presença dos stakeholders. Já o Planning Poker deve ser feito nas Reuniões de Refinamento da Sprint.

Caso não dê tempo para estimar o retorno e nem o esforço antes da Sprint Planning (Planejamento da Sprint), eles terão que ser feitos durante ela. Nesse caso, leve biscoito, frutas e café, pois será demorado.

Duração?

Se tudo for feito com time-box, no geral essas reuniões não passarão de 2 horas por Sprint. Caso a Sprint seja de uma semana, 1 hora de reunião para realizar as estimativas.

Cálculo do RoI para Priorização de Backlog

Agora temos um Backlog com o Retorno Esperado e o Investimento. Podemos calcular o RoI.

Para cada item, dividimos o Retorno obtido pela técnica de Buy a Feature pelo Investimento obtido através do Planning Poker.

Agora podemos priorizar os itens de Acordo com o RoI. Os itens com RoI mais elevados devem ser feitos primeiro.

Backlog priorizado pelo RoI. Para cada item é apresentado o Retorno (somatório do Buy a Feature), Investimento (esforço estimado pelo Time de Desenvolvimento no Planning Poker) e a divisão de um pelo outro para calcular o RoI. A ordem é Item C (RoI é igual a 75 dividido por 3, RoI é igual a 25), Item E (RoI é igual a 70 dividido por 5, RoI é igual a 14), Item D (RoI é igual a 25 dividido por 2, RoI é igual a 12,5), Item A (RoI é igual a 45 dividido por 4, RoI é igual a 9) e Item B (RoI é igual a 85 dividido por 13, RoI é aproximadamente 6,5).
Backlog priorizado pelo RoI.

Algumas considerações

Quick Wins

Neste exemplo tivemos o item D que não possui muito valor, porém o investimento é baixo. Normalmente são os Quick Wins (vitórias rápidas). O item tem valor e o time gastará pouco o esforço para realizá-la.

Por favor, fatie.

Também tivemos o item B que tem muito valor, mas um RoI baixo. Esses casos podem ser um indicativo para que o Product Owner fatie o item. Quanto melhor o faturamento, maior o RoI.

Chegou um novo item no Backlog. O que fazer?

Algumas vezes não conseguiremos reunir os stakeholders para fazer o Buy a Feature. Quando isso acontecer, temos que ter em mente que estamos abrindo mão de algumas coisas. Nós podemos:

  • Aguardar enquanto juntamos mais histórias e convocar uma reunião com os stakeholders. Nesse caso, o Backlog ficará incompleto por mais tempo.
  • Utilizar a inteligência coletiva do Time Scrum para estimar o retorno. Utilizaremos mais tempo do time para estimar.
  • Product Owner estima. Não utilizamos a inteligência coletiva e aumenta a carga sobre o Product Owner.

Fatiei uma história. O que faço com as fatias?

Em tese, todo o processo é repetido. Use o bom senso.

Devo utilizar essas estimativas sempre?

Particularmente, prefiro utilizar métricas mais pragmáticas, tangíveis e comparativas. Para medição de Retorno, Métricas de EficáciaNet Promoter Score (NPS), Receita, Churn, Conversões, Interações do consumidor final com o produto ou serviço, etc. Para o Investimento utilizo Métricas de Eficiência: Customer Lead Time, System Lead Time, Dependências Externas, etc.

Enquanto essas métricas não existem, usamos as estimativas.

Quer aprender mais sobre isso. Veja o nosso treinamento de Certified Scrum Product Owner (CSPO). Faça exemplo na prática e aprenda muitas técnicas essenciais para evoluir na sua carreira de PO.

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Sobre o autor(a)

Trainer na K21

Avelino Ferreira é formado e mestre em Ciência da Computação. Teve uma longa trajetória na TI, começando como programador e chegando a gestor de diversos times de criação de produtos digitais. Conheceu e começou a adotar as melhores prática de de Métodos Ágeis em 2008. Desde então, se dedica a auxiliar outras empresas na construção da cultura ágil. Atualmente, é Consultor e Trainer na K21

Artigos relacionados

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

É uma pergunta comum em diversos times ágeis: Temos capacidade para atender a demanda? A resposta é não. Como diz Rodrigo de Toledo: “No trabalho do conhecimento, a demanda sempre irá superar a nossa capacidade de atendê-la.”. O desafio é…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Data storytelling. Se você acompanha o nosso blog, já deve ter percebido que eu gosto muito de trabalhar com métricas, dados e gráficos. É interessante, mas esses artefatos, apesar de serem interessantes, sozinhos eles não vão dizer muitas coisas. Você…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

A criação de personas é um dos passos mais importantes no desenvolvimento de produtos, mas pode ser um desafio quando se trata de reunir dados e representá-los de forma precisa. Neste artigo, vou mostrar como usamos a inteligência artificial para…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Políticas explícitas são o alicerce invisível que mantém times ágeis funcionando com eficiência e harmonia. No contexto do Kanban, elas são mais do que simples regras: são acordos claros que orientam decisões, promovem transparência e evitam confusões. Apesar disso, muitas…