Um pressuposto implícito feito pela maioria das equipes ágeis é que o 'valor' é algo diretamente proporcional à 'velocidade' da equipe. Ainda que isto possa ser verdadeiro em alguns casos, no entanto, na maioria das vezes a velocidade da equipe dá pouca indicação sobre o verdadeiro valor entregue.
Ryan Shriver sugere que o valor é uma medida dos benefícios entregues, como percebido pelos interessados do projeto (stakeholders). Por outro lado, velocidade é um agregado de pontos por história que uma equipe pode entregar durante uma iteração. Dizer-se que todos esses pontos por história entregam valor é questionável. De acordo com Ryan, as equipes de desenvolvimento devem procurar responder às seguintes questões,
Responda a esta questão: O que é mais importante para as pessoas que financiam seu projeto/produto/serviço? Seriam os benefícios que elas esperam da solução, tais como aumento de lucro, mais participação no mercado ou eficiências operacionais (vamos chamar isto de valor de negócio)?
Ou seria a estimativa precisa do trabalho da equipe na solução (velocidade)?
De forma semelhante, Mike Cottmeyer sugere que valor e velocidade não estão explicitamente correlacionadas entre si. Quando uma equipe inclui novas características com rapidez ao software, atinge assim uma grande velocidade. Entretanto, se a equipe de vendas não é capaz de vender o produto ou se a equipe de negócio não for capaz de usá-lo, então a equipe atualmente vai estar adicionando pouco valor. Ele observa que a definição de valor para um produto complexo pode depender do valor adicionado por todas as equipes da cadeia. Segundo Mike,
Digamos que você tenha quatro equipes que tenham de trabalhar juntas para lançar um novo pacote de produtos no mercado. As equipes A, B e C têm uma velocidade fantástica, mas a equipe D não está sendo capaz de integrar os módulos em sua etapa. A equipe D acaba por atrasar o lançamento... e o produto acaba chegando mais tarde ao mercado. Nesse meio-tempo... a concorrência acaba por lançar a última versão do produto deles, ganhando espaço no mercado e fazendo com que o desempenho do seu produto no mercado acabe não sendo tão bom.
O quanto que a velocidade das equipes A, B e C ajudou no valor final de seu produto? Novamente... uma grande velocidade... mas um valor não tão grande assim.
Então, se velocidade é imperfeita, qual a melhor medida de produtividade?
Kai Gilb’s sugere a regra Valor do Product Owner . Ele mostra como Valor de Interessado e Valor de Produto podem ser integrados com Scrum para uma medida de valor. Aqui, o Product Owner planeja, prioriza e rastrea os resultados em termos de valores de Interessado e de Produto.
Já Ryan Shriver sugere outras técnicas para medidas de valor.
James Shore sugeriu uma maneira interessante para se medir produtividade, chamada de Velocidade de Valor . De acordo com o próprio,
A dica é: ao invés de solicitar que seus especialistas de negócio meçam valor de negócio depois da entrega (difícil!), diga para eles estimarem este valor a priori. Cada história (ou recurso--continue lendo) é estimada antes de ser agendada. Ao final de cada iteração, some os valores das estimativas para as histórias que você concluiu na interação. Esta é a sua "velocidade de valor". É como a velocidade tradicional, exceto que é baseada nas estimativas de valor de seus clientes ao invés de estimativas de custo de seus programadores.
Como a velocidade nem sempre reflete a produtividade real de uma equipe, a chave é medir valor entregue e tornar concretos os esforços para melhorar as entregas de maior valor (ao invés de as de maior velocidade) em cada iteração.