Sorry, this entry is only available in Português.

what you wantEsse é o segundo artigo inspirado na leitura do livro "Conversations For Action and Collected Essays: Instilling a Culture of Commitment in Working Relationships", Fernando Flores e Maria Letelier.

No primeira artigo (O Scrum Coordena Ações de Forma Completa) discutimos como os quatro ato de fala essenciais para o sucesso de uma conversação para ação aparecem no SCRUM.

Lembramos que esses quatro atos de fala são:

  1. o pedido do cliente,
  2. a promessa do executor,
  3. a entrega pelo cliente e
  4. a aceitação pelo executor.

Uma questão importante no livro é sobre como os interesses do cliente devem ser endereçados pelo executor quando tenta completar as condições de satisfação do cliente em relação à ação sendo tomada.

É importante entender que um cliente, quando solicita um objeto ou serviço, não está diretamente interessado naquele objeto ou serviço, o que eu chamo em sala de aula como o "objetivo" do cliente, mas sim em atingir alguma meta de negócio, o que eu normalmente defino como o "interesse do cliente". Assim, quando um cliente solicita um relatório, por exemplo, não está propriamente interessado no objeto relatório, mas sim na forma como vai usar as informações do relatório.

A questão importante é que os pedidos são normalmente feitos de forma objetiva, muitas vezes escondendo deliberadamente as preocupações ou interesses do cliente. Assim, se um cliente deseja poder estudar quais seus melhores clientes ele provavelmente vai pedir para a equipe um "Relatório de Venda por Cliente, ordenado pelo valor comprado". A equipe, desconhecendo o verdadeiro interesse, vai fazer exatamente esse relatório, atendendo as condições de satisfação explícitas, mas não atendendo condições implícitas.

A solução para isso é não só entender O QUE deve ser feito, mas PORQUE deve ser feito.

Uma história do usuário bem definida deve dar essa informação ao desenvolvedor.

Consultando a página de Wikipedia para "user stories" é possível encontrar pelo menos quatro formatos básicos. Não é de se espantar que três desse formatos não se preocupem apenas com o que deve ser feito, mas também o porquê de estar sendo feito.

O formato original de uma User Story é:

Como <papel>, eu quero <objetivo/desejo> de forma a <benefício>

Assim nosso pedido deveria ser inicialmente:

— Como gerente, eu quero o relatório de vendas ordenado por valor, de forma a conhecer meus melhores clientes.

Já podemos ver que a equipe poderia perguntar um pouco mais e propor outros relatórios, ou outras formas de entregar a informação "melhor cliente", ou questionar qual é esse valor (receita total, lucro total, período de tempo, etc…). Porém, como a verdadeira função do desenvolvimento é entregar valor, Criss Matt sugere uma inversão:

Para <receber benefício> como <papel>, eu quero <objetivo/desejo>

No nosso exemplo:

— Para conhecer meus melhores clientes, como gerente, eu quero o relatório de vendas ordenado por valor.

A diferença é pequena, mas podemos entender que o foco da frase muda do relatório para o motivo.

Finalmente, minha preferida usa o conceito do 5W.

Como <quem> <quando> <onde>, eu quero <o que> porque <porque>

No nosso exemplo:

— Como gerente, até o dia 30 de julho, para usar durante a reunião de vendedores, eu quero o relatório de vendas por cliente ordenado por valor porque quero conhecer meus melhores clientes.

E, após uma discussão hoje em uma reunião de projeto poderia ainda adicionar:

Como <quem> <quando> <onde>, eu quero <o que> porque <porque>, por <quanto>

No nosso exemplo:

— Como gerente, até o dia 30 de julho, para usar durante a reunião de vendedores, eu quero o relatório de vendas por cliente ordenado por valor porque quero conhecer meus melhores clientes, por até 8 pontos de esforço.

Dessa forma, conhecendo os verdadeiros interesses do PO, a equipe pode realmente agir para melhorar o projeto ao fazer sua promessa.