El mapeo de historias de usuario (User Story Mapping) consiste en ordenar historias de usuarios a lo largo de dos dimensiones independientes. El "mapa" organiza las actividades del usuario a lo largo del eje horizontal en un orden aproximado de prioridad (o "el orden en el que describiría las actividades para explicar el comportamiento del sistema"). El recorrido hacia abajo del eje vertical, representa una sofisticación creciente de la implementación. En la presentación se da a conocer el proceso de su construcción.
2. ¿Qué es el User Story Mapping?
El mapeo de historias de usuario (User Story Mapping)
consiste en ordenar historias de usuarios a lo largo de dos
dimensiones independientes. El "mapa" organiza las
actividades del usuario a lo largo del eje horizontal en un orden
aproximado de prioridad (o "el orden en el que describiría las
actividades para explicar el comportamiento del sistema"). El
recorrido hacia abajo del eje vertical, representa una
sofisticación creciente de la implementación.
Dado un mapa de historia (Story Map) organizado, la primera
fila horizontal representa al "esqueleto andante", una versión
básica pero utilizable del producto. Trabajando mediante filas
sucesivas se desarrolla el producto con funcionalidades
adicionales.
https://www.agilealliance.org/glossary/storymap/
3. Beneficios
● Visión compartida: Todos los involucrados construirán una visión compartida del
producto a obtener.
● Alineación: Los miembros del equipo y negocio podrán estar alineados sobre lo que
se va a construir.
● Mejor entendimiento de lo que quieren los clientes: Mediante el modelado de los
clientes y de lo que van a hacer con el producto.
● Mejor entendimiento de los problemas que enfrentan los clientes: Lograr un alto nivel
de empatía con los clientes, tanto por participar en la dinámica, como también por
tener la oportunidad de ponerse en el lugar del cliente.
● Un mapa de historias de usuario ordenado por versión: Se puede definir el conjunto
de historias que conformarán el Mínimo Producto Viable (MPV), así como una idea
inicial de las siguientes versiones.
4. Usuarios
Un mapa cuenta la historia sobre un tipo de
persona que hace algo para alcanzar un
objetivo. Se debe incluirlos en su mapa junto
con un poco de información sobre ellos.
Hacer uso de bocetos livianos sobre personas
para describir a sus usuarios.
Tareas de usuario
Son frases verbales cortas que son el bloque básico para la
construcción de un mapa. Si preguntamos a alguien ¿Qué hizo
hoy al usar el correo electrónico? es probable que responda
con tareas como:
• Leer un mensaje de correo electrónico
• Responder a un mensaje
• Marcar un mensaje como spam
Columna vertebral
Las actividades y tareas en
un nivel de objetivo superior
establecen la estructura del
mapa de historia. La columna
vertebral está ordenada en
un flujo narrativo. Subtareas
más pequeñas, detalles y
variaciones cuelgan para
formar las costillas
conectadas a la columna
vertebral.
Flujo narrativo
El eje que va de izquierda a derecha está
organizado en el orden en que se
contaría la historia del usuario a otra
persona.
Por supuesto, cualquier usuario
específico puede optar por hacer cosas
diferentes en un orden diferente. Usar la
conversación para explicar los detalles y
las variaciones.
Si se está buscando la precisión de un
modelo de flujo de trabajo, diagrama de
flujo o modelo UML, entonces un mapa
de historia no es la mejor opción.
Un mapa de historia requerirá mucha
conversación para usarse de manera
efectiva. Lo cual es el propósito de las
historias.
División de Releases
Trazar una recta para identificar sectores de tareas con los cuales los usuarios podrían usar el software para alcanzar sus objetivos. El
número más pequeño de tareas que permitan a usuarios específicos alcanzar su objetivo componen un Release de producto viable.
Usar división de Releases para identificar pequeños experimentos, Releases de mínimos de productos viables o una versión de "esqueleto
andante" (walking skeleton) del producto.
Identificar los Outcomes objetivos de su división en una nota adhesiva o tarjeta a la izquierda de la división.
Detalles, Detalles ...
Dividir las tareas de un nivel de objetivos superior en:
• Subtareas
• Tareas alternativas
• Excepciones
• Detalles
Abajo, en los detalles del mapa, se debe incluir detalles sobre cómo
se vería la UI o qué podría hacer el sistema en segundo plano.
Actividades
Organizan las tareas realizadas por
personas similares en momentos
similares para alcanzar un objetivo. Para
el software de correo electrónico, las
actividades pueden incluir:
• Revisar la bandeja de entrada
• Configurar el cliente de correo
electrónico
• Organizar los mensajes en carpetas.
5. Proceso de construcción
1. Enmarcar.
2. Mapear el panorama general.
3. Explorar.
4. Mapear en releases viables.
5. Dividir la estrategia De Desarrollo en fases.
6. Enmarcar
Antes de mapear, crear un breve resumen del
producto o feature para enmarcar y restringir lo
que se va a mapear. Pensar como si tratase de
una gran historia.
Qué
Nombrar el producto, feature a agregar a un
producto o problema que se quiera resolver.
Quién
Nombrar los diferentes tipos de usuarios que
usarán el producto, y el "selector" o clientes que
lo comprarán. Para cada usuario y "selector",
indique el beneficio que obtienen al usar el
producto.
Por qué
Describir el beneficio que obtiene la
organización al crear el producto o feature.
Indicar qué hacen los usuarios y cómo su uso
conduce a mayores ingresos o menores costos.
1
7. Mapear el panorama general
Concentrarse en obtener toda la historia.
Pensar "un milla de ancho, una pulgada de
profundidad". Las actividades y las tareas de
usuario de alto nivel que cuentan toda la
historia forman la columna vertebral del mapa
de historia.
Comenzar con el tipo de usuario más crítico
para el éxito del producto. Imaginar un día
típico en la vida del usuario con el nuevo
producto. Mapear los pasos que dan como
tareas de usuario de izquierda a derecha.
Identificar las actividades de los usuarios:
grupos de tareas que trabajan juntas para
respaldar un objetivo común. Las actividades a
menudo surgen después de ver más sobre una
historia.
Agregar usuarios adicionales. A medida que se
siga el uso común del producto, es posible que
otros tipos de usuarios ingresen a su historia.
Continuar modelando la historia de izquierda a
derecha.
2
8. Explorar
Completar la estructura del
mapa de historias
dividiendo las tareas de
usuario más grandes en
subtareas más pequeñas y
detalles de la interfaz de
usuario.
Usar esta fase para pensar
creativamente sobre todas
las grandes posibilidades.
Aprovechar este tiempo
para pensar en todo lo que
podría salir mal. No
preocuparse si las ideas
están "dentro o fuera del
alcance". Deliberadamente
se apartaran las cosas
fuera del alcance más
adelante.
● Jugar "no sería genial si ..." para
ayudar a pensar en grandes ideas
de productos.
● Buscar variaciones: ¿Qué más
podrían haber hecho los usuarios
del sistema?
● Buscar excepciones: ¿Qué podría
salir mal y qué tendría que hacer
el usuario para recuperarse?
● Considerar a otros usuarios:
¿Qué podrían hacer otros tipos de
usuarios para alcanzar sus
objetivos?
● Agregar otros detalles del
producto como: Descripción de la
UI propuesta; Reglas del negocio;
Data elements.
Involucrar a otras
personas. Contar la
historia del producto a
otras personas que
comprendan a los usuarios
y su uso. Ellos encontrarán
agujeros en la historia y
ayudarán a construirla.
Contar la historia del
producto a los
desarrolladores de
software. Ellos indicarán
áreas riesgosas o costosas
e incluirán excelentes
soluciones tecnológicas.
3
9. Dividir en releases viables
Dividir el mapa en
Releases de productos
integrales que comprendan
a los usuarios y el uso del
producto.
Estas divisiones forman un
Roadmap de Releases del
producto, donde cada
Release es un Producto
Mínimo Viable (MVP).
Para cada Release, indicar los
Outcomes y el Impacto objetivos.
Los Outcomes y el Impacto indican
cómo este Release contribuye al
objetivo general y cómo los usuarios
se van a comportar de manera que
ayuden a alcanzar el objetivo.
Para cada Release,
identificar las métricas de
éxito del producto.
Responder a la pregunta:
"¿Qué mediríamos para
determinar si este producto
fue exitoso?" Idealmente,
se encontrará cambios
específicos en el
comportamiento de los
usuarios a medida que
usan el producto de la
forma en que se encuentra
plasmada el mapa de
historias.
4
10. Dividir la estrategia De Desarrollo en fases
Divida la primera versión
de su mapa en tres o más
fases de entrega que le
permitan a usted y a su
equipo aprender
rápidamente y evitar
riesgos. Piense en las
fases de apertura, mitad y
final del juego de un juego
de ajedrez.
Esta estrategia de
desarrollo lo ayudará a
lanzar el mejor producto
posible en las limitaciones
de tiempo que tiene.
● En la fase inicial, crear la versión
funcional más simple posible del
producto (functional walking
skeleton). A su finalización, revisar
el producto con los usuarios y
Stakeholders. Comenzar a validar
el rendimiento y la escalabilidad.
● En la fase intermedia, completar
todas las funcionalidades
principales y hacer que aquellas
existentes sean mejores y más
completas. Seguir con las pruebas
de usuario y aprovechar el
feedback para ajustar el producto.
Continuar con la validación del
rendimiento y la escalabilidad.
● En la fase final, refinar el producto
para su lanzamiento. Considerar el
trabajo imprevisto que surgirá
durante este último tramo de
desarrollo.
Planificar el trabajo
necesario para refinar
historias.
Realizar talleres sobre
historias con
desarrolladores y testers
para trabajar en los
detalles y acordar los
criterios de aceptación.
Planificar el desarrollo y
las pruebas.
Construir y verificar partes
de software funcionando.
5
11. Referencias
● Story Map Concepts
○ https://www.jpattonassociates.com/wp-content/uploads/2015/03/story_mapping.pdf
● User Story Mapping. Discover the whole story, build the right product
○ https://www.amazon.es/User-Story-Mapping-Discover-Product/dp/1491904909
● ¿Cómo se hace un User Story Mapping?
○ http://scrum.menzinsky.com/2018/11/como-se-hace-un-user-story-mapping.html