Tenho notado que a criação e priorização de estórias de usuários no Product Backlog, bem como o desenvolvimento de software de maneira incremental, vem apresentando um comportamento de output (saída) e não de outcome (resultado).

Ou seja, os times estão se preocupando mais com a quantidade de entregas (output), do que com os resultados (outcome) e os impactos que deveríamos gerar para o negócio.

Esse comportamento pode ser notado quando as estórias do usuário são criadas, divididas ou priorizadas sem a visão do fluxo de valor do produto.

De uma maneira mais lúdica seria como cozinharmos um bolo apenas com uma parte da receita e ainda sim esperar que no final dos preparos tenha-se um bolo. Imagine que dependendo da divisão feita na receita, não conseguiremos ao menos entregar algo comível (testável) para nosso cliente/negócio.

Quer ver um exemplo?

Podemos utilizar uma parte da técnica de User Story Mapping, criado por Jeff Patton, para ajudar os times a se libertar do fardo de tentar escrever documentos perfeitos e de acreditar que compartilhar documentos é o mesmo que compartilhar entendimento.

Sendo assim, o User Story Mapping tem como intenção a utilização de estórias para compartilhar entendimento e não documentar o trabalho a ser feito.

De uma forma bem direta e prática podemos dividir a técnica em quatro etapas, sendo extremamente importante que o time participe ativamente de todo o processo, dizendo o que pensa e fazendo perguntas.

A dinâmica será muita mais produtiva se pudermos exteriorizar nossos pensamentos desenhando ou organizando nossas ideias em cartões ou post-its. Com isso, construímos um entendimento compartilhado, mitigando o risco de diferentes entendimentos.

 

Conheça as 4 etapas para utilização do User Story Mapping

1. Definição de fluxo de valor

Precisamos criar o que o autor chama de “Big Story”, que é um fluxo que irá contar a interação dos usuários com o produto para atingir o objetivo desejado. Esse será o nosso ponto de partida para o User Story Mapping.

Veja o exemplo a seguir:

2. Criação do Backbone, coluna vertebral

A partir do fluxo de valor criado na etapa anterior, iremos identificar ações que contenham o mesmo contexto de iteração do usuário, agrupando-os em épicos. Esses épicos serão representados por colunas que futuramente nos auxiliarão a identificar o trabalho por contextos diferentes.

Observe:

3. Criando, dividindo e organizando estórias

Agora que temos o fluxo de valor definido e agrupado por épicos (contexto) podemos criar, dividir e organizar as estórias em seus respectivos épicos (colunas). É importante deixar claro para o time que esse momento, literalmente, será de contar estórias e não de escrever estórias.

Utilize pequenos cartões ou post-its para escrever pequenas sentenças que nos ajudem a lembrar como aquela estória será usada, estando sempre atento para não se perder nos detalhes.

Lembre-se: Essas estórias ainda serão refinadas (vamos discutir a fundo os detalhes da tarefa e remover maiores incertezas técnicas e de negócio) e que por hora concentre-se na amplitude da estória antes de mergulhar na profundidade.

4. Priorização, definições de incrementos

Estamos quase lá!

No final da terceira etapa teremos uma visão geral do fluxo de valor, da divisão por épicos e das estórias de usuário. Agora, precisamos definir a ordem de execução do trabalho, priorização das estórias, baseado em incrementos que entreguem valor para o negócio.

Faremos isso traçando linhas horizontais e as identificando como incrementos. Note que agora teremos células geradas a partir do cruzamento das linhas verticais de épicos e as linhas horizontais de incrementos.

Dentro de cada célula o time deverá eleger quais estórias estarão contidas, considerando o épico (contexto) e a relevância para a entrega de valor, considerando percorrer todo o backbone e consecutivamente atendendo o fluxo de valor dos usuários.

Observe o exemplo:

Conclusão

Foi percebido que quando a criação, divisão e organização das estórias de usuários é realizada sem o entendimento do fluxo de valor e do backbone (coluna vertebral) da ideia, os times têm a tendência de trabalhar com profundidade nos épicos, colunas verticais. Com isso, geram incrementos de software que não permitem o cliente validar o fluxo do valor.

Quando o time tem o entendimento do fluxo de valor e do backbone (coluna vertebral) da ideia é possível organizar o trabalho com mais amplitude no fluxo de valor e menos profundidade nos épicos, gerando incrementos de valor para cliente.

Espero que vocês tenham entendido a utilização do Story Mapping nos quatro passos acima e que ao praticarem este novo conceito, consigam perceber a diferença e entrega de valor na técnica mostrada.

Aguardo vocês no próximo artigo, até lá.