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.
Está sem tempo para ler? Experimente ouvir este artigo!
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
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.
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:
- Reúne-se um grupo de stakeholders, pessoas interessadas no produto / serviço que estamos construindo. Se possível, os consumidores finais.
- Apresentamos os itens de valor descritos no backlog.
- Cada pessoa receberá 100 moedas. Você pode utilizar dinheiro de jogos, fichas de poker ou apenas post-its indicando o valor.
- As pessoas devem “comprar” os itens de backlog. Para tal, elas distribuirão as 100 moedas conforme elas desejarem.
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.
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…
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
- 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.
- O Time de Desenvolvimento escolhe o item mais fácil de ser construído e atribui o valor 2 para esse item.
- 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.
- 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.
- O Scrum Master pede então para que as pessoas “joguem” (apresentem as suas estimativas).
- 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.
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).
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 do 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.
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ácia: Net 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.
