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?

Story Mapping

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:

Definição de fluxo de valor

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:

Criação do Backbone

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.

Criando, dividindo e organizando estórias

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:

Priorização, definições de incrementos

 

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á.