valorEsse artigo é baseado em uma discussão em uma reunião de projeto e propõe para discussão mais ampla uma pequena adição opcional ao SCRUM.

A questão discutida foi:

Quanto vocês estimam de esforço para fazer o que vou pedir.

O motivo foi que o PO necessitava de uma função porém, como não era essencial, só estava disposto a pagar uma certa quantidade de pontos de esforço por ela. Caso ela ultrapassasse o limite estabelecido por ele, outras funcionalidades eram mais importantes.

A proposta que fica é que o PO sempre tenha ideia de qual o valor, em pontos de esforço, ele estaria disposto a pagar para ter certa funcionalidade e ficar satisfeito. Representaria, de certa forma, o "preço justo" do PO para aquela funcionalidade.

Isso lembra um pouco a prática original de definir o valor de negócio da história de usuário, porém a unidade daquele valor nunca foi estabelecida como a mesma unidade de esforço, e o conceito de preço justo também nunca foi citado.

Por que isso seria útil?

Primeiro, podemos ao longo do tempo acertar o conceito do "preço justo" com o "preço técnico", aquela previsão de esforço feita pelo Time. Isso faria com que o PO tentasse compreender melhor a dificuldade de implementação das funcionalidades e também que a equipe tentasse entender melhor se sua velocidade está atendendo as expectativas do usuário.

O estabelecimento da razão preço justo/preço técnico, que chamaremos de razão de produção, também serviria como padrão de produtividade que ajudaria a balizar uma equipe SCRUM em relação às outras, principalmente quando o PO fosse o mesmo. Assim, uma equipe que produzisse duas vezes mais pontos de esforço que outra equipe só teria essa diferença confirmada caso sua razão de produção fosse a mesma.

Também ajudaria a definir prioridades, pois implementar histórias com maior razão de produção é mais eficiente e provavelmente agregaria maior valor ao PO.

Como desvantagens, podemos analisar que seu uso no início do projeto é bastante complicado para o PO. Porém, podemos estabelecer uma técnica semelhante à usada para estabelecer o padrão de medida de pontos de esforço, i.e., escolher a menor tarefa do primeiro Backlog de Produto e dar o valor 2 para ela.

A ideia é que após a equipe estimar pela primeira vez suas histórias o PO daria o preço justo para elas de forma que a história que adicionasse a menor quantidade de valor na primeira Sprint tivesse o preço justo de 2.  

Fica agora para o leitor a pergunta: você já fez algo parecido? Qual a sua opinião? Qual a sua experiência?