Dificuldade na priorização do backlog e definição de releases?

Vamos falar sobre Story Mapping!

Você que já participou de uma equipe de desenvolvimento de software, provavelmente já se deparou com as dificuldades enfrentadas por profissionais de produto para priorizar o backlog e definir releases. Essas tarefas podem se tornar ainda mais difíceis sem as ferramentas e técnicas ideais, distanciando os releases dos principais objetivos do projeto e criando features desnecessárias para o produto.

Para ajudar a resolver esses problemas, vamos detalhar neste blog post o uso do Story Mapping, conhecido para alguns e um grande mistério para outros. Essa ferramenta foi criada por Jeff Patton e descrita mais profundamente no livro  “User Story Mapping”, do mesmo autor.

Num primeiro momento, pelo nome, você deve estar pensando que serve apenas para mapear itens de trabalho. E se eu disser que com o uso do Story Mapping você pode ainda potencializar a entrega de valor de cada release, alinhar expectativas de entrega entre stakeholders e despriorizar tudo aquilo que não se faz essencial para a entrega? O Story Mapping não vai salvar e resolver todos os problemas do seu projeto, mas vai ser muito útil especialmente em dois momentos: no início do projeto, quando está se criando um produto e não se tem uma direção para seguir, ou após uma mudança de objetivo que altere todo o escopo planejado.

PASSO 1 – Montagem do Fluxo de Valor

Para iniciarmos o Story Mapping, primeiramente precisamos ter um fluxo de uso ou uma Big Story que vai narrar a interação do usuário com o produto , levando em conta o caminho que o usuário percorre para atingir o objetivo que esse produto se propõe a resolver. Essa será a linha de base para o Story Mapping.

Caso ainda não tenha esse fluxo, ele pode ser montado em uma dinâmica com os donos do produto e o time envolvido na criação do mesmo, expondo suas visões do que seria ideal o produto realizar. Geralmente utilizamos o fluxo de valor ou o principal artefato (objeto principal do produto) para nortear a discussão.

PASSO 2 – Mapear histórias

A segunda etapa é o momento de analisar o fluxo, identificando etapas que tenham o mesmo contexto ou que sejam originadas de uma mesma ação do usuário, gerando assim os principais épicos, que servirão de base para o levantamento dos itens de trabalho. Os épicos servirão como um backbone (coluna vertebral) do story mapping.

Chegou então a hora de detalharmos o que precisa ser feito dentro de cada épico. Essas serão as histórias de usuário (ou itens de trabalho, se preferir chamar assim) que serão desenvolvidas. Deixo claro aqui que essas histórias ainda passarão por refinamento, que é o momento que, de fato, vamos discutir a fundo os detalhes da tarefa e remover maiores incertezas técnicas e de negócio. O objetivo aqui é apenas mapear os itens de trabalho, e não detalhar e escrevê-los. No exemplo da imagem abaixo ainda temos os temas, sendo este um agrupamento lógico de épicos com o mesmo contexto dentro do sistema.

Antes de falar do próximo passo, uma dica: tenha objetivos claros, priorizados e factíveis sobre o projeto, para que se possa definir os releases com maior entrega de valor. Quando se planeja um produto, geralmente se tem um objetivo a ser atingido e se espera que ele agregue um valor estimável ao negócio. Caso os objetivos estejam genéricos ou amplos demais, recomendo que este objetivo seja fatiado em partes menores que poderão se tornar outros milestones de entregas do produto. Por exemplo, você pode ter um MVP (Minimum Viable Product), do seu produto. Esse primeiro release poderá entregar valor para o negócio mais rapidamente e, mesmo que seja feito de forma mais simples, vai permitir a coleta de métricas de produto, validar hipóteses sobre o que está sendo feito e aumentar a entrega de valor de releases futuros.

PASSO 3 – Definição dos Releases

O terceiro e último passo é, após ter os principais objetivos mapeados e priorizados, fazer a distribuição dos itens de trabalho da etapa anterior entre esses objetivos. Uma boa maneira de fazer isso é traçar raias no seu board de Story Mapping, onde cada raia representa um objetivo e, assim, facilitar a distribuição dos cards. Veja o exemplo abaixo:

Se fatiamos o backlog, nas fatias horizontais teremos os objetivos e as histórias, enquanto na vertical teremos os épicos com suas respectivas histórias. Durante a distribuição de histórias e objetivos, ou até mesmo durante o desenvolvimento do produto, certamente irão aparecer outros itens que antes não haviam sido mapeados, mas o escopo estará bem mais detalhado e direcionado para o que precisa ser feito após as discussões.

Com a participação de todos os stakeholders na dinâmica para definições de fluxo, épicos, histórias e releases, ganhamos em alinhamento de expectativas sobre as entregas, definição de um MVP que faça sentido para o negócio e um direcionamento das próximas etapas do projeto.

Para dar continuidade ao tema de priorização de backlog e definição de releases valiosos para o negócio, deixo aqui a recomendação de um post sobre métricas de produtos, escrito aqui na Plataformatec: O que seriam boas métricas para produtos digitais?

E você? Já tem a visão do backlog e releases do seu projeto? Deixe seus comentários abaixo sobre sua experiência com o Story Mapping!