User Story Mapping es una técnica ágil que permite organizar el Product Backlog en dos dimensiones con la intención de visualizar las funcionalidades del producto por una parte y por la otra los releases del producto. La técnica fue propuesta por Jeff Patton en el año 2005 y es muy utilizada por su sencillez y claridad al momento de definir las entregas. Cuando se trabaja con un Product Backlog como una lista priorizada de requerimientos es probable que no se logre tener una visión global del producto y como sus funciones están interrelacionadas. User Story Mapping es una forma visual de mapear el Product Backlog que permite al equipo tener una visión común del producto que deben construir.
En este artículo examinaremos la forma en que se construyen estos diagramas, sus beneficios y recomendaciones de uso.
Contenido
¿Qué es User Story Mapping?
Es una técnica utilizada en la concepción de un producto: permite esbozar un nuevo producto o una nueva característica para un producto existente,
El resultado es un diagrama en que todas las historias de usuario están ordenadas en grupos funcionales. Esto ayuda a no perder de vista el panorama general, a la vez que proporciona todos los detalles de la aplicación en su conjunto.
¿Por qué es útil un User Story Mapping?
Un User Story Mapping facilita el descubrimiento del producto y la priorización del trabajo de construcción. Esto se consigue poniendo las actividades y tareas del usuario en un mapa que sirve para mantenerlas en contexto.
El User Story Mapping muestra cómo cada historia de usuario individual se inserta en el conjunto de la aplicación. Esto permite detectar vacíos y realizar una priorización consistente.
Características ágiles de los User Story Mapping
Este diagrama se centra en el usuario, es decir, alguien que está íntimamente familiarizado con el trabajo que su aplicación va a soportar y los problemas que va a resolver. Es por esto, que esta herramienta permite un grado muy alto de comunicación y análisis con los usuarios.
Los User Story Mapping facilitan la respuesta al cambio debido a que si hay una modificación en las historias de usuario (agregar, modificar o eliminar) es fácil detectar qué más hay que añadir, cambiar o eliminar.
¿Cómo se confecciona el Story Mapping en seis pasos?
Para confeccionar adecuadamente un User Story Mapping se debe pensar todo el proceso desde el punto de vista del usuario (De ahí el nombre de esta técnica). Se deben considerar los objetivos que busca el usuario con el sistema. La palabra usuario indica a quien usa el sistema y no otro rol dentro del equipo SCRUM.
A continuación se detallan los pasos a seguir para construir correctamente un User Story Mapping en seis pasos
1- Empezar por las Épicas, grandes historias o bloques de funciones
Se debe identificar las grandes historias o partes del sistema. Esto es equivalente a identificar actividades amplias que ejecutan los usuarios y que el sistema debe soportar. Son grandes historias porque tienen muchos pasos. Estos pasos no necesitan tener un orden o flujo de trabajo específico. Muchas actividades de usuario tienen pasos que un usuario hará en forma asincrónica, es decir, en diferentes momentos y en diferentes horarios.
Cada actividad se escribe en una tarjeta o post-it. Se ordenan de manera que tengan sentido para el usuario. Si el usuario indica que una actividad y luego otra entonces, se deben representar en ese orden. Si las actividades no se hacen una tras otra, entonces se debe emplear el orden en que el usuario las menciona. De esta forma el diagrama que se va construyendo sirve para la comunicación con el equipo y otros usuarios.
Por ejemplo, si está construyendo una plataforma para gestionar “conciertos”. Los visitantes de la plataforma pueden buscar “conciertos” a los que asistir. Los visitantes pueden unirse a esos “conciertos”. Los miembros de la plataforma pueden asociarse y crear nuevos “conciertos”. El equipo detrás del sitio actúa como moderador y comprueba si los nuevos eventos están dentro de las directrices.
Los grandes bloques o épicas de esta plataforma se pueden graficar como en la figura 1.
Las dos primeras épicas están asociadas al usuario “visitante”, en cambio la última está asociada al usuario “administrador”
2- Descomponer las Épicas en historia de usuario más simples.
Posteriormente se debe descomponer o dividir cada épica en historias más pequeñas, las tareas del usuario. Estas tareas se deben colocar bajo la actividad a la que pertenecen y ordenadas en la misma dirección que las actividades y en el orden que tenga sentido para el usuario.
En nuestro ejemplo esto podría quedar como la Figura 2.
De esta forma se puede ver que se tiene la columna vertebral del sistema.
A continuación se deben poner las tareas asociadas a cada historia, las que se deben poner debajo de la correspondiente historia hacia abajo como se indica en la figura 3:
3- Revisar la completitud del diagrama
El diagrama expone todo el sistema de manera ordenada y desde el punto de vista de los usuarios. Esto permite que se pueda revisar y completar con todo aquello que en una primera revisión no apareció.
En el ejemplo esto podría quedar de la siguiente forma:
La idea es que el User Story Mapping quede completo con toda la información que suministren los usuarios. Se deben incluir los puntos que son especialmente sensibles como también aquellos que el usuario espera que estén incluidos.
4- Ordenar las tareas según su importancia
En este paso se deben ordenar por orden de importancia las tareas dentro de cada historia. Arriba deben quedar las tareas que son más importantes y hacia abajo las que menos.
Cada historia y sus tareas se pueden ordenar por prioridad sin considerar las historias vecinas.
En el ejemplo esto quedaría así
5- Definir entregas
El siguiente paso es definir las entregas o release. Se deben seleccionar de cada historia las actividades que son esenciales para obtener una primera versión del producto con estas funcionalidades. Esto viene a constituir un MVP (Producto mínimo viable).
En el ejemplo esto podría quedar así:
6- Definir siguientes entregas
Finalmente, se deben planificar las siguientes entregas que pueden realizar siguiendo el mismo procedimiento planteado en el punto anterior. También es posible que la siguiente entrega corresponda a una historia específica con todas sus tareas.
Este instrumento es dinámico. por lo que se puede volver al punto tres y repetir el proceso en la medida que se identifiquen nuevas historias y tareas.
Beneficios de User Story Mapping
Los siguientes son los principales beneficios:
- Todo el mundo puede entender fácilmente la aplicación en su totalidad
- El User Story Mapping es una forma de comunicar lo que resuelve la aplicación y cómo lo hace para todos los usuarios de la misma. Esta técnica permite que todos los involucrados puedan participar en su creación.
- Permite tener un panorama general de la aplicación a la vista, lo que facilita el alineamiento de los equipos de desarrollo.
- Elaborar y tener visible un User Story Mapping facilita el desarrollo iterativo e incremental.
- Muestra dónde ubicar una historia de usuario en todo el sistema en una sola vista.
- Ayuda a decidir qué construir primero. Facilita la selección de historias de usuario de diferentes características que, en conjunto, proporcionarán un valor para los usuarios. Es decir, se facilita la definición y construcción de MVP.
- Esta técnica evita más fácilmente construir algo que no funcione.
- No se perderán ni olvidarán partes importantes que lo haría inutilizable.
- Permite visualizar el mapa de historias para comprobar si hay vacíos y detectar dónde falta algo.
- Permite tomar decisiones de priorización teniendo en cuenta el contexto de toda la aplicación.
- Este diagrama facilita la colaboración y ayuda a la comprensión compartida.
- El contexto completo que proporciona este diagrama ayuda a dimensionar rápidamente las historias de usuario en relación con las demás.
Principales errores
Los siguientes son algunos de los errores que se comenten:
- Trabajar sin un cliente o alguien íntimamente familiarizado con su trabajo. Es esencial incluir a los usuarios para que se capturen todas las épicas, historias y tareas.
- No mantener visible el mapa. El no hacerlo produce que el diagrama queda desactualizado y no se usa.
- No centrarse en problemas a resolver. Es necesario identificar los problemas que los usuarios deben resolver.
Ver más sobre Metodología Agile
User Story Mapping es una técnica ágil que permite organizar el Product Backlog en dos dimensiones con la intención de visualizar las funcionalidades del producto por una parte y por la otra los releases del producto.
La técnica fue propuesta por Jeff Patton en el año 2005 y es muy utilizada por su sencillez y claridad al momento de definir las entregas.
Un User Story Mapping facilita el descubrimiento del producto y la priorización del trabajo de construcción. Esto se consigue poniendo las actividades y tareas del usuario en un mapa que sirve para mantenerlas en contexto.
Para confeccionar adecuadamente un User Story Mapping se debe pensar todo el proceso desde el punto de vista del usuario. Se deben considerar los objetivos que busca el usuario con el sistema.
Los seis pasos son:
1- Empezar por las Épicas, grandes historias o bloques de funciones
2- Descomponer las Épicas en historia de usuario más simples.
3- Revisar la completitud del diagrama
4- Ordenar las tareas según su importancia
5- Definir entregas
6- Definir siguientes entregas
El User Story Mapping permite tener una visión global del producto y como sus funciones están interrelacionadas, detectar vacíos y realizar una priorización consistente. Además, facilita la respuesta al cambio debido a que si hay una modificación en las historias de usuario es fácil detectar qué más hay que añadir, cambiar o eliminar.
Uno de los principales errores es tratar de incluir demasiada información en un solo diagrama. Es importante limitar el detalle para evitar que el diagrama se vuelva difícil de leer. También se debe evitar el uso de jerga técnica que solo el equipo de desarrollo entienda y no el usuario.
