Introducción al User Story Mapping

En Agile siempre que trabajamos en el inception deck hacemos énfasis en la importancia de establecer una visión, un entendimiento compartido entre el equipo de lo que se está construyendo a partir de aquí es necesario desglosar esa visión a través del uso de las diferentes técnicas como el User Story Mapping.

Pero una vez que tienes una visión, es importante preguntarse:

  • ¿Cómo la traducirías a una colección de historias de usuario para crear una cartera de productos?
  • ¿Cómo se ponen las historias de los usuarios en orden de prioridad?
  • ¿Y cómo te aseguras de no haber dejado fuera alguna funcionalidad importante?

Manteniendo el enfoque en el valor

Para generar una visión de producto comenzamos enumerando los diferentes usuarios y sus necesidades, las características que ayudarían a satisfacer esas necesidades y el valor que se generaría.

Así que ya tenemos algunas características que pueden formar la base de nuestra cartera de productos.

Pero sería un error empezar a tratar de construir nuestro backlog a partir de estas características por sí solas, despojadas de su contexto y desvinculadas del valor que se supone que deben entregar al usuario y al negocio.

En lugar de ello, deberíamos considerar el cuadro de visión del producto como la primera iteración de algo que necesita concretarse en todas sus dimensiones, no sólo en la dimensión “características”.

Se requieren más trabajo y conversaciones entre los desarrolladores, gerentes de producto/propietarios, analistas de negocio y diseñadores de UX sobre quiénes son nuestros usuarios, y la mejor forma de satisfacer sus necesidades de manera viable y que cree valor para la organización.

Hicimos muchas suposiciones cuando elaboramos nuestra visión de producto, suposiciones que ahora necesitan ser validadas o descartadas a medida que entran en contacto con la investigación exhaustiva de los usuarios (tanto cualitativa como cuantitativa), las personas y las conversaciones con las partes interesadas del negocio.

Necesitamos una buena técnica para captar la comprensión del equipo del producto a través de todos estos desarrollos.

Introducción al User Story Mapping o (al mapeo de historias)

El mapeo de historias es una técnica defendida por Jeff Patton. Nos proporciona una forma de concebir todo el producto o servicio como una serie de tareas que el usuario completa.

En términos puramente prácticos, implica la construcción de una cuadrícula de historias de usuario que se presentan bajo encabezados que representan la experiencia del usuario moviéndose a través de su producto.

Esto se puede hacer de forma iterativa a través de una serie de conversaciones entre los miembros del equipo. Así que un primer intento podría parecerse a esto, con historias de usuarios agrupadas bajo sus respectivas características (algunos podrían llamar a estas características de alto nivel Épicas).

user story mapping

Aquí tenemos las características de alto nivel de nuestro producto (la columna vertebral, si lo desea) desglosadas en historias de usuario de componentes.

Es fácil ver a qué función pertenece cada historia de usuario y, por lo tanto se presenta en el contexto del producto completo, no sólo como un elemento de una lista.

Si bien este enfoque es útil para organizar nuestros pensamientos -ya es mucho más informativo que una simple lista de historias-, en realidad todavía no constituye un mapa de la historia, ya que no tiene en cuenta el flujo del usuario (customer journey).

Desarrollo del Story Map

Hagamos nuestro ejemplo más concreto imaginando un sitio web de ecommerce simple, donde el tablero de visión del producto hace referencia a tres características:

  • Página del producto
  • Búsqueda de productos
  • Pago

El mapa inicial de la historia podría verse así:

flujo story mapping

Tenemos la función “Página de producto” con las historias de los usuarios relacionadas con esa función que se encuentra debajo, y lo mismo ocurre con las funciones “Buscar productos” y “Pago”. Pero estas historias no están particularmente bien desarrolladas todavía, y no hay indicación de cuán importante es cada una de ellas.

Por ejemplo, un usuario necesita leer una descripción del producto antes de realizar un pedido, pero ¿eso sucede antes o después de haber leído las opiniones? ¿Y qué ofrece más valor al usuario?

Después de que se lleve a cabo más investigación y se reúnan más aportes de las partes interesadas, otra iteración podría parecerse a ésta.

story mapping flujo 3

Observe que hemos refinado nuestras historias de usuario rompiendo algunas de ellas en pedazos más pequeños, hemos introducido una nueva dimensión en la que las historias se organizan por orden de donde vienen en el viaje del usuario, y hemos comenzado a organizar las historias de mayor prioridad cerca de la parte superior de nuestro mapa.

Desarrollándonos más en esta dirección, es fácil ver cómo, eventualmente, podríamos llegar a un mapa que indique qué historias necesitamos incluir en los primeros lanzamientos.

resultado story mapping

El story map es un proceso iterativo

Todos estos detalles habrán surgido de una conversación entre los miembros del equipo y las partes interesadas sobre la mejor manera de ofrecer el valor más alto posible para el usuario y el negocio lo antes posible.

El mapa de la historia proporciona un marco para esa conversación, una forma de representar visualmente las ideas durante la conversación, y una manera de registrar los resultados que, a diferencia de un trabajo atrasado de producto plano, captura todo el contexto del viaje del usuario.

El mapa de la historia, como el producto mismo, es siempre un trabajo en progreso. Nos da una instantánea del pensamiento del equipo en ese momento.

A medida que continuamos nuestras discusiones con los usuarios y las partes interesadas, a medida que se van acumulando más pruebas que validan o invalidan nuestras suposiciones, el mapa de la historia puede cambiar y desarrollarse en consecuencia.

Al agrupar las historias de los usuarios por función, el mapa de la historia asegura que creamos lanzamientos significativos que permiten a los usuarios completar viajes de extremo a extremo.

Nos ayuda a construir una primera versión que sea un producto mínimo viable y luego iterar sobre ella, aportando nuevo valor al negocio y al usuario con cada nueva versión.

Poniendo en práctica

verifyserptrade