User Story Mapping – Mais colaborativo não dá!

Com certa frequência alguém me pergunta sobre conhecer ou não uma técnica indicada para o levantamento de requisitos em uma cultura ágil, a primeira que me vem a mente é a “User Story Mapping”, criada por Jeff Patton, então colei uma foto e link com o artigo original dele – How you Slice It (pdf), recomendo a leitura dele, mas a seguir explico como nas equipes que trabalho nós fazemos:

Jeff Patton

Elicitação x US Mapping

No mindset antigo, o início era o processo de elicitação, entrevistas individuais e algumas reuniões com diferentes usuários e stackholders, para então o analista ir para sua sala ou baia e passar dias transcrevendo, diagramando, colocando no papel seu entendimento e conforme a urgência já saía de lá com a lista de tarefas.

A US Mapping é uma técnica ágil utilizada para levantar e organizar requisitos, exigindo apenas a combinação de um mediador experiente, uma parede (tão grande quanto o projeto), muitos postits, canetões, fita crepe e os convidados que podem e devem contribuir para a visão dos desejos relativos ao produto.

Quanto ao número de pessoas, já participei de US Mapping com mais de 10 pessoas, entretanto, creio que se ultrapassar muito disto há o risco de tornar-se muito lento ou confuso, achei referências a até 12 pessoas como limite, mas sei de reuniões desta natureza com mais de doze.

Quanto ao tempo, pode durar um turno, um dia ou mais, conforme estiver claro para os participantes quanto ao entendimento do que esperam do produto, quão complexo pode ser, mas mais que regras de tempo é importante bom senso e um facilitador experiente. Tudo isto, é claro, contando com as pessoas certas – PO, UX, SEO, executivo, keyusers, referências do business, técnicas e criativas.

Preparação e ambientação

Use uma mesa em que todos estejam bem confortáveis, junto a uma parede bem grande e desimpedida, sem móveis ou quadros, dê um bloco de PostIts amarelos para cada um, um canetão com ponta fina e alinhe com todos como as US devem ser escritas (parto do princípios que Agile já não é novidade para eles e que todos sabem o porque estão ali, o formato e trouxeram algumas reflexões).

Na parede, risque ou cole uma fita crepe montando um eixo cartesiano (xy), sendo o X um prisma pela SEQUÊNCIA de eventos, como por exemplo, um site de busca tem a necessidade de uma home com a caixa de busca antes da página de resultados, e o Y tem um prisma de RELEVÂNCIA ou VALOR:
eixo-xy
Inicie com uma apresentação geral do que já se sabe para entendimento da estratégia, pontos de atenção, oportunidades, riscos,  é bom manter um clima aberto, sem pressão ou repressão, todos podem sugerir e falar livremente, acho que o valor maior é bom senso, educação e convicção de que vale a pena.

Desenvolvimento

Defina uma ordem em que um por vez irá sugerir uma US, de forma cadenciada, mas sem stress, pois a comunicação e entendimento do que cada US sugerida é importante para evitar esquecimentos ou redundância, na prática existe uma fila circular em que todos vão sugerindo uma nova US na sua vez ou passe a vez para o próximo caso não tenha nada para sugerir.

A cada postit (US) sugerida, o próprio integrante que a propôs ou o mediador a coloca em uma posição dos eixos XY e rapidamente todos podem colaborar para sua disposição, mais para cima ou para baixo caso seja mais ou menos relevante, direita ou esquerda para refletir sequencialidade.

A cada novo postit (US) colocado, é possível que não só este seja reposicionado nos eixos XY, mas outros podem ter que se adaptar comparativamente, isto é mais que previsível, posto que é impossível coincidir que os postits (US) surgirão do mais relevante para o menos e do primeiro ao último na sequencia.

Informações adicionais podem ser combinadas e introduzidas através de postit’s pequenininhos de outras cores, destacando situações especiais importantes e já percebidas em alguma US, podendo ser tamanho PMG, valor BMA, responsável, todas informações e ajustes das posições podem mudar, pois na medida em que novos postits (US) entram, a comparação entre eles fica cada vez mais clara.

eixo-xy

Concluindo

Na medida em que evolui a reunião, o quadro vai se compondo de tal forma e vai se formando uma linguagem ubiqua (comum), quer pelos argumentos ou debate realizado a cada rodada, gerando sensação de unidade e convergência entre os diferentes participantes, reforçando o senso de pertença e clareza nos porquês de valor e priorização.

Importante salientar que postits (US) com baixa priorização ou desconsiderado, abaixo do eixo X, tiveram debate apropriado e na falta de argumentação suficiente, ficará claro a todos, inclusive de seu “criador” a fragilidade de seus argumentos, cabendo melhorá-los (os argumentos) ou aceitar o dequalificação.

Por outro lado, o fato de não estar na primeira linha (mais relevantes ~ valor) ou não estar na primeira coluna, não quer dizer que ficará para depois ou não será feito, a montagem de Releases e Sprints possui diversos prismas, como negócio, co-requisitos, dependências, oportunidades, tecnologia, oportunidades e riscos.

Release Plan

Por fim, o planejamento de Releases e talvez já esboçando suas Sprints é feito em um esforço conjunto que busca dividir em “pacotes” o todo, explicitando o que  se percebe como mais importante, corelações importantes, desenhando-se uma linha de tempo e suas entregas, com uma ou mais Releases, cada uma com uma ou mais Sprints.

A primeira linha são as US mais relevantes, que agregam mais valor ao produto, mas pode ser que algumas de nível 2, 3,4 sejam requisito para outras de nível maior, sendo assim, não há uma resposta simples do tipo, primeiro façam as 1, depois as 2, etc … Na verdade, cada Release ou Sprint fracionada terá uma composição racional de alto valor pelo seu conjunto.

A partir dos acordos negociados durante este exercício de Mapping, uma solução hipotética pode ser como abaixo fracionado, reiterando que não termina aqui, pelo contrário, esta recém começando, o PO montará seu product backlog, compartilhará o Release Plan e a cada Sprint Zero confirmará o Sprint Backlog com o time durante o Planning.

A combinação poderia ser toda a primeira linha, seria o exemplo mais fácil, mas como eu nunca vi isso acontecer, mostro um exemplo que me parece mais realizada nos nossos cases, em que vai-se mergulhando na solução cada vez mais a cada Sprint, entregando páginas e funcionalidades:

eixo-xy1

Um comentário sobre “User Story Mapping – Mais colaborativo não dá!

  1. Pingback: Um ano e meio de blog – Obrigado galera! | Jorge Horácio "Kotick" Audy

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

w

Conectando a %s