Durante um processo ágil de gestão o Product Owner é encarregue de definir a prioridade das estórias. Na teoria ele deve fazer isso baseado pesando o valor e o tamanho da estoria.  A prioridade é um numero relativo que ordena as estorias no backlog e não ha espaço para empate; todas as estorias devem ter prioridades diferentes. Contudo as metodologias ágeis terminam na fronteira do Product Owner assumindo que ele vai se virar  sozinho para avaliar o valor da estoria e depois compará-lo com o tamanho e priorizar o backlog. O como ele vai fazer isso é uma variável mágica.

No mundo real, contudo, o Product Owner tem que responder a vários stakeholders e o valor advém principalmente da expectativa e demanda que esses stakeholders têm em relação às features desenhadas nas estórias. Isto deixa o Product Owner numa posição muito subjetiva de ter que adivinhar os desejos de prioridade de todas as partes interessadas e, pior que isso, conseguir ordená-las.

O método

No seu livro “Software Requirements“, Karl Wiegers demonstra um método que poderia ajudar nesta situação. Embora o método não tenha sido desenhado para aplicar num ambiente agil,  o conceito é simples o suficiente para ser adaptado.A atratividade é uma relação entre o valor, o custo e o esforço.

O Valor

Para chegar no valor da  estoria pedimos a cada parte interessada que pontue de 1 a 9 o beneficio que aquela estoria traz, sendo 1 uma estoria com o menor beneficio e 9 com o maior beneficio. Depois pedimos que pontue de 1 a 9 a penalidade de abandonar aquela estoria, sendo 1 uma estoria que não traz penalidade abandonar ( ninguém iria sentir falta dela) e 9 uma estória que tem maior penalidade ao ser abandonada (muitas pessoas iriam reclamar).

O valor será então a soma do beneficio com a penalidade. Assim, uma estoria que tem beneficio 1 mas penalidade 9 é equivalente em valor a uma que tem beneficio 9 e penalidade 1.

Esta pontuação pode ser definida apenas pelo PO no caso em que as partes interessadas não são tão interessadas assim para as fazer responder um questionário. O PO continuará confiando no seu tato e feeling, mas pelo menos será obrigado a colocar isso numa escala. Um trabalho semelhante ao que a equipa faz para pontuar o tamanho das estorias.  No caso geral, contudo, ele elaboraria um questionário e pediria que fosse respondido pelos stakeholders. Esta é uma prática já comum na área de jogos, por exemplo, onde as features são avaliadas por questionário respondidos por potenciais jogadores antes de serem incluídas para desenvolvimento.

Este método permite ao PO atribuir ao parâmetro de valor um numero, em uma escala relativa, que está diretamente relacionada à demanda e expectativa dos stakeholders em relação à estoria.

Pode acontecer que existam poucos stakeholders com que o PO pode interagir, por limitações variadas. Neste caso o PO deve procurar por mais partes interessadas ainda que “remotamente interessadas” e atribuir pesos diferentes às opiniões dadas pelos stakeholders principais e pelos secundários.  A ideia é que o PO deve aumentar a abrangência do grupo de stakeholders de forma a ter uma melhor ideia das suas demandas e expectativas. O tamanho do grupo, os papeis que essas pessoas desempenham em relação ao produto e a forma como pesar as demandas de cada um varia conforme o produto e as próprias pessoas envolvidas. O PO deve equacionar isso quando estabelecer critérios de como será levantada a pontuação de beneficio e penalidade. No caso extremo o PO necessitará de uma equipa própria que o possa auxiliar nessas tarefas.

O Custo e o Tamanho

O custo no método descrito por Wiegers é equivalente ao conceito de Tamanho em ágil. Estamos interessados numa medida relativa do quão grande é cada estória. Então, no caso agil, o PO usará as estimativas de tamanho em pontos de estoria estimada pela equipa por métodos como o planning poker.

O Risco

O risco também é avaliado pela equipa junto com o tamanho. O risco é a probabilidade de 1 a 9 de que a estoria não vai atender à demanda dos stakholders à primeira.  O risco não está relacionado à probabilidade de completar a estoria no sprint, nem relacionado ao cone de incerteza. Este  risco do método descrito por Wiegers está relacionado  à probabilidade de, uma vez ponta, a funcionalidade incluída pela estoria não satisfaça os stakeholders interessados.

As razões para o risco são muitas. Desde de um fraco levantamento de requisitos a uma equipa inexperiente nas tecnologias necessárias passando por uma fraca usabilidade ou um aspecto gráfico “feio”.

No modelo explicado por Wiegers existe a opção deste fator ser ignorado num primeiro uso do método e integrado na medida em que descobrir que as estorias não satisfazem os stakeholders. Isso pode ser controlado pelo numero de vezes que uma mesma funcionalidade, cenário de uso, ou tecnologia usada na implementação são modificados depois de estarem pontos.

A atratividade

Baseado no valor  (calculado pela soma do beneficio com a penalidade) no tamanho e no risco , calculamos a Atractividade da estoria ( que Wiegers chama também de Prioridade,mas em agil esse nome tem outro significado). A atratividade (A)- o quanto a estória é atrativa – é calculada da seguinte forma:

Onde v é o valor da estoria, t é o tamanho da estoria e r é o risco da estoria. V é a soma de todos os valores de todas as estorias, T é a soma de todos os tamanhos e R de todos os riscos. Este conceito de “todos” pode ser aplicado ao product backlog ou ao release backlog. Estamos interessados em ter uma medida relativa. Porque as estorias no backlog mudam (entram e saiem) a atratividade irá mudar nesse momento, o que é exatamente o que seria esperado empiricamente.

Se desconsiderarmos o risco, numa primeira aproximação, a formula se transforma em :

O fator T/V será igual para todas as estorias e igual a uma constante que apenas afetará o valor numérico da Atratividade mas não o seu valor relativo. Neste caso, simples, em que removemos o fator de risco, a atratividade se resume ao quociente entre o valor e o tamanho.

Atratividade e Prioridade

A razão pela qual não podemos considerar diretamente que a atratividade é equivalente à prioridade é  que a prioridade implica num valor diferente para cada historia, coisa que a formula da atratividade não garante. Então, no fim, o PO ainda terá que desempatar algumas estorias com atratividade igual, mas pelo menos agora ele terá que fazer isso apenas em alguns casos e não em todos. A atratividade é um coeficiente que pode ajudar a guiar a decisão do PO, mas é apenas uma formula matemática que não está sujeita a pressões de stakeholders.

Adaptação

O método descrito por Wiegers usa escalas de 1 a 9 para pontuar o beneficio, a penalidade o risco. Escolher uma escala decimal é natural ao ser humano, portanto a escolha de numeros menores que 10 é muito feliz neste método. Contudo, das práticas de estatística, sabemos que escalas impares fazem com que respostas a questionários tendão para o valor central sendo sempre melhor oferecer um numero par de opções. Por estas razões poderiamos aumentar a escala até 10, diferenciando o 5 e o 6 como uma indecisão mas com peso para um dos lados.

Um outro detalhe é que o valor numérico da atractividade vai variar entre numeros menores que um ( 1/13) e maiores que 1 ( 10 /1). O que pode confundir o PO ao comparar o numero 0, 00769 com 10, por exemplo. Além de implicar em regras de arredondamento chatas. Por outro lado, como a Prioridade normalmente usa numeros bastante grandes poderiamos aplicar um fator numérico à atractividade descrita por Wiegers para ter uma escala mais “humana” apenas com números inteiros e mais próxima da escala de Prioridade. Multiplicando por 100 mil, teríamos valores mais compráveis, por exemplo 1.000.000 e 7.692 eliminando o problema do arredondamento.

A ditadura dos números

Com esta técnica não apenas ganhamos uma forma de atribuir um numero e uma escala relativa ao Valor, mas ganhamos uma forma de comparar o Valor com o Tamanho de uma forma simples, que pode atuar como uma forma rudimentar de priorização. Contudo não podemos encarar este método como uma forma à prova de falha ou que substitui o discernimento do PO. É apenas uma ferramenta auxiliar para ajudar o PO a decidir, mas de nenhuma forma pode ser considerada a resposta definitiva que dita a prioridade das estórias.

Não é porque a teoria “maistream” das metodologias ágeis ignora os problemas do dia-a-dia do Product Owner e confia no seu senso de valor que temos não podemos sugerir uma forma um pouco mais “cientifica” de fazer as coisas olhando as boas práticas das metodologias clássicas. Afinal queremos um Product Owner que tome decisões baseado em fatos, não em suposições. E definitivamente não queremos um Product God que toma controle de tudo baseado nos sues próprios interesses.