Visual User Story Mapping Aplicado

User Story Map
En el 2011 asistí a un workshop donde tuve oportunidad de conocer la técnica de Visual Story Mapping de su ideador, Jeff Patton.


User Story Map es una herramienta que permite generar una representación visual de la sistema completo. Ofrece una vista general de todas las funcionalidades que lo componen (the big picture) de punta a punta. Permite identificar User Stories faltantes en el Backlog, planificar Releases partiendo en rebanadas (Slicing), visualizar cómo se distribuyen las funcionalidades de acuerdo a las diferentes áreas del sistema.

Es una forma de reorganizar el Product Backlog en dos dimensiones, una dimensión para el tiempo (medido en Releases) y otra dimensión para las funcionalidades.



¿Cómo se construye?

Para la construcción resulta fundamental pensar todo el proceso desde el punto de vista del usuario y sus objetivos con nuestro sistema; nunca desde el lugar de Product Owner o de quienes construimos el producto u ofrecemos el servicio.

  1. Backbone: Identificar las grandes etapas en las que se divide nuestro sistema. Por ejemplo, en un sistema de venta online, podría ser: llegar al website, búsqueda de producto, compra/pago y entrega.
  2. Activities: Identificar todas las actividades que debe o puede realizar el usuario en nuestro sistema, desde que llega al mismo hasta que finaliza su proceso. Ordenarlas de manera secuencial de manera horizontal. Esta secuencia conforma la cadena de valor de nuestro sistema (Value Stream).
  3. User Stories: Identificar las distintas maneras que nuestro sistema puede ofrecer para que el usuario realice cada una de las actividades identificadas. Por ejemplo, para la actividad "encontrar producto" podría ser: navegar el catálogo, usar el cuadro de búsqueda, sugerencias de productos, etc.
  4. Priorización: Cada columna debajo de cada Activity funciona como un backlog que debe estar priorizado por relevancia. Para la priorización debemos utilizar el criterio de MoSCoW (Must Have, Should Have, Could Have). De manera que la funcionalidad más elemental, que no puede faltar debe estar primera.

The Walking Skeleton

Con las activities y la primera fila de User Stories obtenemos lo que Jeff Patton denomina "The Walking Skeleton" (el esqueleto que camina) porque está completo y funciona, aunque sea en su forma más elemental.

Nuestro producto en este estado puede ser identificado como la versión MVP (Minimum Viable Product). O como él lo llama, MMF (Minimum Marketable Feature).




Release Planning

El User Story Mapping permite planificar las próximas versiones o releases del producto representando de manera visual en qué partes de nuestro sistemas estamos dedicando mayor esfuerzo para generar Incremento de Producto.

Esto puede ser muy poderoso, como estrategia de negocio si se lo asocia al Customer Life Cycle para comprender qué partes de nuestro sistema debe ser mejoradas.





El Poder Visual

El User Story Map permite a cualquier stakeholder comprender qué funcionalidades ya fueron realizadas, cuáles se están trabajando en este momento y cuales son las próximas funcionalidades para todo el producto y la organización.

User Story Map y la Estructura Organizacional


El User Story Map, está centrado en el usuario y representa el flujo del producto de punta a punta, por lo tanto integra a muchos (sino todos) los equipos de la organización, promoviendo alineamiento de prioridades una visión más integral. 

En las metodologías ágiles se recomiendan los equipos por funcionalidad del producto (Feature Teams) y la herramienta de User Story Map se adapta perfectamente a esta estructura. Es probable que un equipo se dedique a implementar determinadas actividades y por lo tanto se identifique con determinadas columnas del Story Map. 

La herramienta permite visualizar si la carga de trabajo pendiente se corresponde con la capacidad o tamaño de los equipos de desarrollo.

Si la organización estructura los equipos como Component Team (equipos por plataforma) se pierde esta capacidad de visualización. Sin embargo, se podría utilizar código de colores para identificar al equipo. 

Formas de Implementación (Por eso el "Aplicado" en el título)

El User Story Map suele requerir mucho espacio físico, lo cual puede representar un desafío.

En la Pared

El Story Map se puede implementar directamente sobre la pared con Post-its y cinta de enmascarar. La única limitante es que queda fijo en una pared y requiere reservarse este espacio para trabajar con la herramienta. Esta es la forma más recomendada de implementarlo. La mayoría de las empresas lo utilizan de esta manera, en un espacio común de la empresa.

De esta forma funciona com un potente radiador de información.


User Story Map



¿ Story Map Portátil ?


¿Qué tal si el equipo se reúne en distintas salas de la empresa y necesita un Story Map trasladable? Una buena idea es emplear paneles Foamboard (o alguna otro panel rígido) y unirlos con cinta de enmascarar o papel, de manera que puedan plegarse.

En el caso de la foto utilicé 3 paneles de 1 x 0,7 metros c/u. De esta manera, el Story Map se puede plegar y trasladar para llevarlo a las salas de reunión o dejarlo visible en el espacio de trabajo del equipo.


La versión digital

Al igual que los tableros de tarea de Kanban y Scrum (Taskboards), se puede implementar también con software. Sin embargo, debería ser la última alternativa a elegir, ya que tienen una exposición más reducida y el potencial que tienen las herramientas visuales y colaborativas se ve muy disminuido con herramientas abstractas.

La única ventaja que encuentro, es en el caso de equipos remotos distribuidos.

En caso de elegir esta opción hay muchas opciones disponibles. Por nombrar algunas.

  • CoardBoard (https://cardboardit.com/) es una herramienta online para construir User Story Maps de manera colaborativa.
  • Real Time Board (https://realtimeboard.com/) no es una herramienta específicamente diseñada para User Story Map pero sirve perfectamente.
  • Agile User Story Map es un plugin que se integra automáticamente con Jira 
  • Stories on board http://storiesonboard.com/

Agregando una tercera dimensión

Siempre es buena idea utilizar el color del post-it como una tercera dimensión para identificar información extra.  Por ejemplo, para un producto multi plataforma, identificar cada plataforma con un color distinto.


Múltiples Usuarios

Qué sucede cuando nuestro producto hay más de un usuario? Es muy probable que cada tipo de usuario tenga su propia secuencia de actividades. Un Story Map debe representar a un solo flujo de usuario. Únicamente en el caso donde la diferencia es muy leve y no se justifique crear otro Story Map, se podría identificar con código de colores las actividades del usuario secundario.



Tal vez te interese....

Para seguir aprendiendo (en inglés)


Entradas populares de este blog

Historia de las Metodologías Ágiles en Contexto

Los Bugs en Scrum