User Story Mapping

Es una técnica descrita por primera vez por y consiste en representar el product backlog en dos dimensiones en vez de en una.

¿Para qué sirve?

Al construir el User Story Map al principio del proyecto, sirve para tomar decisiones y provocar muchas conversaciones que posteriormente serán útiles durante la construcción. Durante el resto del proyecto es muy útil para no perder el horizonte sobre lo que se pretende construir.

¿Cómo se construye?

Representamos verticalmente las diferentes versiones en las que iremos construyendo el producto, con lo que uno de los resultados que obtenemos al realizar un User Story Map es nuestro plan de versiones.

Representamos horizontalmente las tareas de usuario (o User Tasks). Las podemos agrupar en actividades de usuario (o User Activities). Las tareas de usuario son ya muy parecidas a una Historia de Usuario porque representan una acción que realizará un usuario.

UserStoryMap-esquema-blog

Las tareas de usuario se distribuyen horizontalmente, según el orden en el que éstas serían usadas para completar un uso normal. Por ejemplo, el usuario primero accede al sistema, luego busca un producto, lo añade a la cesta de la compra, paga y finalmente recibe una notificación de la compra.

Haremos crecer el User Story Map verticalmente añadiendo capas de funcionalidad completa y coherente para los usuarios. Es lo que llamamos construir un producto de manera iterativa e incremental. La primera capa se denomina el “walking skeleton”, “bala trazadora” o primera versión que pondremos a disposición de los usuarios para recibir feedback.

Si nuestro “walking skeleton” coincide con el MVP estaremos en disposición de ponerlo en la calle a disposición de los usuarios, pero a veces esto no es deseable y debemos esperar a tener alguna capa más de nuestro producto. En cualquier caso, el User Story Map nos ayuda a trazar un plan de construcción iterativa e incremental de nuestro producto.

A veces, las tarjetas representan épicas, es decir, historias demasiado grandes y ambiguas como para llamarlas historias de usuario. Otras veces son muy detalladas y las terminamos agrupando a la hora de construirlas. Como en cualquier otro proceso de refinamiento, el “grano” adecuado de las tarjetas lo iremos encontrando a medida que debatimos sobre ellas.

¿Cuándo se construye?

Para realizar un User Story Map es aconsejable que haya una idea suficientemente madura de lo que se quiere construir, de lo contrario puede ser muy costoso llegar a una idea común. Un buen momento para hacer el User Story Map es al final de la Agile Inception.

Es aconsejable que estén presentes el dueño de producto, todos los miembros del equipo y todas aquellas personas que puedan aportar a la hora de explicar el comportamiento esperado del producto. También es interesante contar con quien pueda aportar sobre las prioridades de negocio, puesto que pueden ayudar a tomar decisiones relevantes.

El User Story Map es una técnica relativamente sencilla pero que requiere cierta práctica y que todos los participantes estén orientados a la colaboración. A veces es recomendable encargar a alguien que actúe de facilitador para evitar que los debates se alarguen demasiado.

Para saber más:

  • El artículo original de Jeff Patton y su libro titulado “User Story Mapping”.
  • Presentación del taller que impartí con Javier Alonso () en la Conferencia Agile-Spain 2013 sobre el uso conjunto de técnicas de sketching y pretotipado junto al User Story Mapping.
  • A mí me gusta mucho trabajar las User Personas antes del User Story Map. De esta manera conseguimos que el producto esté mucho más enfocado a los usuarios y que no se nos olviden necesidades internas muy relevantes para el negocio.

One Pingback/Trackback

  • Pingback: Explorando una hoja de ruta para la transformación ágil – Se hace camino al andar…()

  • Alberto Gómez Rodríguez

    Crees que los desarrolladores / UI / UX / QA… deberían estar presentes en las sesiones de User Story Mapping?

    • Hola Alberto.

      Pues sí, en mi experiencia (y es la recomendación de Jeff Patton también) deben estar todos los miembros del equipo porque el objetivo principal es compartir conocimiento y tomar las primeras decisiones de priorización sobre el proyecto en cuestión. Dejarlos fuera implicaría que no habrían estado presentes en esas conversaciones, lo cual podría implicar una revisión de las mismas.

      A veces puede parecer que están “de cuerpo presente”, pero éso puede ser una señal de que son necesarias más conversaciones aún. Yo he observado que, cuando el User Story Map sucede al final de una Inception, esto no sucede, pero depende mucho del contexto de cada proyecto.

      Gracias y un saludo
      JMB