A abordagem ágil para priorização é que as histórias de usuário de mais alto valor de negócio devem ser implementadas antes daquelas de menor valor de negócio. O conceito é simples, mas sua implementação depende de se ter um mecanismo para avaliar o valor de negócio. Pascal Van Cauwenberghe descreveu recentemente uma abordagem para se definir o valor de negócio chamada de “Modelagem de Valor de Negócio”, que pode ajudar.
No artigo de Pascal intitulado Como estimar valor de negócio das histórias de usuário? Não estime, ele postula que há uma falha fundamental na suposição de que as histórias de usuário vêm primeiro e então seu valor de negócio é avaliado. Para Pascal, uma pergunta “Como encontramos Histórias de Usuário que entreguem Valor de Negócio?” fornece um ponto de partida bem melhor. Seguindo nesta abordagem, ele sugere:
- Primeiro decidimos que valores (ou benefícios) queremos alcançar antes de iniciar um projeto ou um produto
- Então, encontramos e melhoramos os processos de negócio capazes de entregar tais valores
- Em seguida, encontramos e melhoramos os processos de negócio de negócio que apoiam os processos passíveis de entregar valor
- Quando o time precisa de histórias de usuários, pegamos os processos de negócio de mais valor e os quebramos em histórias de usuários no nível de granularidade adequado às necessidades do time. A partir, então, deste conjunto de histórias, o time gera apenas um conjunto mínimo de histórias de usuários.
Em uma continuação do artigo, Pascal prossegue examinando o significado do termo “Valor de Negócio”. Ele ainda não está satisfeito com uma única métrica tal como a 'Valor para o Acionista', constatando que normalmente há vários interessados com diferentes objetivos e necessidades. Pascal utiliza um processo que ele chama de "Modelagem de Valor de Negócio":
- Identifique os interessados relevantes.
- Identifique suas necessidades e seus objetivos.
- Chegue a um consenso sobre como medir/testar as expectativas com relação a estas necessidades e objetivos.
- Selecione as – poucas – medidas e testes mais importantes (nossos "Direcionadores de Valor").
- Defina o relacionamento entre os Direcionadores de Valor.
- Utilize tais Direcionadores de Valor para objetivar e priorizar nosso trabalho, do começo ao fim.
Uma abordagem um tanto quanto similar para se atribuir valor de negócio foi descrita por Brandon Carlson no artigo Priorização "em um piscar de olhos". Esta sua abordagem define valor de negócio primeiramente pela identificação dos atributos de uma funcionalidade que contribuem para o valor de negócio. Seu time cria uma lista de tais atributos que levam em conta aspectos como: obrigações contratuais, oportunidades de mercado, impacto no cliente, contexto atual no sistema e estratégias corporativas. Especialistas de negócio em cada área então pontuam o impacto de cada uma das funcionalidades em sua área de conhecimento. Baseado nesta entrada, um número do valor de negócio é calculado para cada funcionalidade proposta.
Uma vez que todos os interessados tenham pontuado seus próprios atributos, as pontuações são computadas e as funcionalidades que tenham maior impacto positivo para o produto são colocadas no topo da lista. Sem discussões (ok, algumas discussões, mas não tanto quanto antes), apenas número... Desde que passamos a adotar esta abordagem, temos comprovado uma melhora considerável na produtividade das reuniões [de priorização]. As prioridades-base são definidas nos primeiros minutos da reunião e o restante do tempo dispendido foi reduzido significativamente, de cerca de uma hora e meia para apenas 30 minutos.
Mike Cohn, nas várias encarnações de sua apresentação "Priorizando Seu Product Backlog", falou de uma variedade de técnicas para se avaliar o valor relativo de negócio. Algumas destas técnicas incluem “Theme Screening” (triagem por tema, “Theme Scoring” (pontuação por tema), “Relative Weighting” (pesagem relativa) e “Kano Analysis” (análise de Kano). Em uma variação desta apresentação, disponível no site da Scrum Alliance, Mike ainda compartilha um modelo financeiro que atribui valor a temas (sendo um tema uma coleção de histórias de usuário relacionadas) em termos de Valor Líquido Presente e Taxa Interna de Retorno.
Em A Métrica da Produtividade, James Shore descobriu que uma maneira de se medir valor de negócio é um pré-requisito para se criar uma métrica satisfatória de produtividade.
Há uma maneira de se medir o trabalho de uma equipe de programadores e que funciona. E isto envolve olhar para o impacto que o software da equipe tem no negócio. Você pode fazer isto medindo a receita, o retorno sobre o investimento ou qualquer outro número que reflita valor de negócio.
Quando James revisitou o assunto em Velocidade de Valor: Uma Métrica de Produtividade Melhor?, ele admitiu que boas métricas para valor de negócio são difíceis de se criar.
Por mais que esta abordagem ainda me agrade, ela também tem suas falhas. Pode realmente ser difícil de se medir valor. Alguns tipos de trabalho que são valorosos não levam a melhorias nas vendas. E também, algumas das causas de melhoria de valor não estão relacionadas ao trabalho do time... alguns tipos de histórias não dão retorno da maneira tradicional. Qual o valor de se corrigir um bug chato que trava o sistema? Seria o próprio valor do software? Ou simplesmente não há nenhum valor? E o que falar sobre o valor dos ajustes finais e do acabamento?
Por último, James sugere a criação de estimativas de valor de negócio, de uma maneira semelhante à que as equipes fazem estimativas de trabalho. Kelly Waters também recomenda esta abordagem no artigo Medindo Valor de Negócio no Desenvolvimento Ágil de Software. Tal como a definição de tamanho de histórias, Kelly utiliza a escala relativa de Fibonacci para atribuir valor de negócio de cada história.
Da mesma maneira que a equipe de desenvolvimento estima em pontos, o Product Owner decide sobre o valor de negócio de cada item com valores relativos entre si. O ponto chave aqui é que o valor de negócio estimado é relativo, i.e., uma funcionalidade com valor de negócio 2 é duas vezes mais valiosa que uma estimada em 1; uma que seja 5 tem valor estimado cinco vezes mais valor que uma que seja 1, e por aí vai... atribuir o valor de negócio em pontos para cada item do backlog nos permite calcular a ‘Velocidade de Negócio’, i.e., quanto valor de negócio (em pontos) está sendo entregue em cada sprint. Você poderia até plotar isto em um ‘gráfico burn-up’, mostrando o valor de negócio acumulado entregue ao longo do tempo.
E a sua organização, como mede valor de negócio? Qual o impacto da priorização do trabalho que os desenvolvedores fazem? Deixe um comentário e compartilhe suas experiências e opiniões.