La magia de hacer que un backlog de historias de usuario cobre vida y cuente una historia

El mapeo de historias de usuarios te permitirá convertir un backlog plano en una excitante historia del viaje del usuario en donde vemos cómo todas las piezas encajan de forma coherente

TL;DR

Uno de los ejercicios que ha cambiado la forma en que trabajo con equipos de producto ha sido el famoso ejercicio de Jeff Patton llamado “User Story Mapping” (mapeo de historias de usuario).

Usualmente, las historias de usuario están en una lista de un backlog, en donde no tienen contexto ni tienen flujo, ni métricas.

El mapeo de historias de usuario sirve para ver cómo todas las historias encajan unas con otras en el tiempo, y también permite crear una estrategia de releases que sea coherente y permita sacar las funcionalidades en el tiempo y medir el impacto que están teniendo en las métricas de producto.

Este ejercicio transformará la forma en que la definición de alto nivel de una nueva iniciativa llega a desarrollo, y permitirá a tu equipo entender qué están construyendo en cada momento y como encaja todo en la foto final.

En resumen, el mapeado de las historias de usuario convertirá el ejercicio de creación de producto en una experiencia mágica de alineamiento de equipo.

Flujo de creación de producto sin mapeo de historias de usuario

Definiendo una métrica

El primer paso coherente que queremos llevar a cabo es poder definir una métrica que queremos mejorar, y que nos permitirá mejorar el negocio.

Parece que este paso es obvio, pero en algunos equipos este paso no se lleva a cabo, se salta el proceso de definición de qué es lo que queremos mejorar y cuanto lo queremos mejorar, y esto genera muchos problemas en el largo plazo.

Y es que si no definimos de manera clara nuestro objetivo, no sabremos si hemos llegado una vez acabado el trabajo.

Pensemos en una funcionalidad de venta de entradas de cine en donde se puedan comprar entradas unas horas antes de que comience la película a un precio reducido.

Podríamos decir que nuestro objetivo es hacer que las salas de cine tengan un 5% más de butacas vendidas comparado con el número de butacas que se vendían antes de tener esta aplicación.

La parte de métricas da para un artículo entero, pero asumamos por simplicidad que hemos sido capaces de definir la capacidad histórica de las butacas del cine, y que podremos medir el aumento de dicha capacidad en base a la venta de entradas que nosotros generamos.

Definiendo una iniciativa

La definición de una iniciativa busca tener una foto a alto nivel qué se quiere hacer, cuales son las hipótesis que se quieren validar y cómo pensamos crear un producto o funcionalidad que valide las hipótesis y consiga las métricas que queremos obtener.

Pensemos en el ejemplo de una aplicación de venta de entradas de cine.

Nuestra hipótesis puede ser que en los cines haya butacas que se quedan vacías y que podemos vender dichas butacas en último momento a un precio de descuento.

En este paso se define el alcance del proyecto a alto nivel, definiendo qué se quiere conseguir con la funcionalidad, las métricas que se quieren obtener

Definiendo esta hipótesis, el siguiente paso podría ser validar dicha hipótesis con un prototipo dinámico de la aplicación.

Validando el prototipo

Una vez tengamos nuestra hipótesis, el siguiente paso que podemos hacer es crear un prototipo dinámico básico que sirva para validar la idea con usuarios reales.

En ocasiones el proceso de discovery lleva a entrevistas de usuarios para entender y validar la hipótesis que queremos confirmar, pero por tiempo dejaremos estos pasos fuera y asumiremos que vamos directamente a una validación de prototipo.

Esta validación se mostrará a posibles clientes una navegación básica sobre cómo y cuando podrían comprar entradas a último momento a un precio reducido.

Esta validación básica nos dará feedback muy útil sobre cómo nuestro prototipo soluciona los problemas de los usuarios

Bajada de historias de usuario en equipo

Una vez validado el prototipo, en muchos equipos se bajan las historias de usuario y se meten en el backlog, y empieza el desarrollo.

La bajada de historias de usuario puede ser iniciada por el product manager o business analyst, pero la confirmación de cómo llevar a cabo la partición de una iniciativa en épicas e historias de usuario debe ser un acto colaborativo entre el equipo.

Este trabajo colaborativo permite poner más ojos en el proceso de desglose del trabajo, y buscar huecos que quizás la persona que haya hecho la bajada inicial de historias quizás no haya tenido en cuenta.

Desarrollo y lanzamiento

Una vez se ha bajado a tierra las historias de usuario, comienza el desarrollo, en donde se groomean las historias y los desarrolladores programan la solución validada.

Cómo y dónde se añade el mapeo de historias de usuario

El momento clave en donde se hace el mapeo de historias de usuario es después de la validación del prototipo.

Trabajo colaborativo para conseguir alineamiento

El trabajo del mapeo de historias de usuario tiene que ser colaborativo, y busca el alineamiento de perspectiva de todos los miembros del equipo.

Mi recomendación es usar inicialmente post-its para este ejercicio, y que todo el equipo esté presente al ejercicio de creación del mapeo de historias de usuario.

Los post-it traen un elemento físico en donde todo el equipo está de pie revisando la propuesta del mapeo de historias de usuario, y los post-it son fáciles de mover de un lado para otro sin ningún problema.

También se puede usar cinta de pintor para separar las diferentes releases y usar post-its permite que el equipo cierre los ordenadores y ponga toda su atención al ejercicio que tiene delante.

Definir los pasos generales de la funcionalidad

En este punto definimos los pasos a alto nivel que tendrá que tomar el usuario para poder llevar a cabo la acción que estamos definiendo.

Esto es fácil llevarlo a cabo cuando se tiene un prototipo dinámico de lo que se quiere construir, y cada uno de estos pasos será una de las épicas del producto.

De forma natural van saliendo los pasos que el usuario tendrá que tomar para completar la actividad sobre la que se está discutiendo.

Veamos el ejemplo de la aplicación de descuentos de cine…

Definir las historias de usuario asociadas a estas actividades de alto nivel

Una vez que las historias a grandes rasgos se han definido, entonces el siguiente paso es ir a los puntos más granulares que se tienen que llevar a cabo.

Esto es, que es exactamente lo que necesitamos hacer para poder completar el trabajo para que la actividad a alto nivel que hayamos definido pueda completarse.

En muchas ocasiones son los propios desarrolladores quienes detectan algún agujero en la definición y pueden ellos mismos explicar lo que falta y añadir el post-it al mapeo de historias de usuario.

Aquí también el equipo de producto tiene el permiso de salirse del guión creado en la iniciativa y proponer nuevas alternativas que quizás no se hayan contemplado en la iniciativa.

Mirando el ejemplo de la compra de entradas a precios reducidos de entradas de cine, se podría proponer alternativas para que los clientes puedan ver las entradas con descuento disponible de forma regular, así como el canal por el cual se comunicarán dichos cambios.

También se puede proponer métodos de pago alternativos que no sea el clásico pago con tarjeta de crédito, y añadir el pago con Bizum o incluso pagar la entrada en la puerta del cine.

Este punto es importante, ya que en vez de cerrar el alcance de una iniciativa a lo originalmente definido, en este punto podemos usar al equipo para poder traer nuevas ideas de desarrollo.

Esto no quiere decir que estas ideas se lleven a cabo, pero si puede guardarse en el backlog de futuros experimentos que nos acerquen a las métricas deseadas.

En el ejemplo de abajo vemos las historias de usuario asociadas a cada una de las épicas, que se añaden al flujo del usuario previamente definido.

Definir las releases de la iniciativa

Una vez definido todo lo que se tiene que hacer, se deberá definir qué se puede desarrollar primero, que tambiénpodríamos llamar MVP, y qué historias podremos sacar una vez el MVP esté desarrollado.

Esta discusión debe permitir a las 3 personas más importantes del equipo, el lider de tecnología, el líder de diseño y el lider de producto, llegar a un acuerdo para poder sacar la mínima funcionalidad posible en una release, pero todo el equipo está invitado a contribuir.

En cualquier caso, siempre es sano poder dividir el trabajo en releases que nos permitan poder tener una perspectiva clara de qué sería lo mínimo para poder tener una funcionalidad que permita al usuario ir de principio al fin del flujo con lo mínimo.

Teniendo esta foto clara, podremos lanzar las diferentes iteraciones del producto para sacar a producción.

Monitorizar las métricas en cada iteración

Otro punto fuerte del mapeo de historias de usuario es la posibilidad de medir en cada iteración el impacto de la métrica inicial que queríamos impactar.

En cada iteración buscaríamos medir el impacto de la funcionalidad en la métrica.

Esto lo podemos escribir en el mapeo de historias de usuario, o tenerlo como una métrica asociada al proyecto dentro del panel de métricas que tengamos para el producto.

En el caso de añadirlo en el mapeo de historias de usuario, pondríamos el impacto de la métrica y la fecha en donde se consiguió esta métrica, tal y como se puede ver en el ejemplo de abajo.

Entrevistas de usuario en cada iteración

Una de las mayores ventajas que creo trae este modelo iterativo y dinámico de creación de producto es que en cada iteración podemos ir a los clientes y presentarles un producto final sobre el que podemos obtener feedback.

Es treméndamente efectivo hablar con clientes que están usando el producto en producción y nos puedan dar feedback sobre algo que ya están usando en su día a día.

Este feedback se puede retroalimentar en el producto y usarse para siguientes iteraciones de la funcionalidad.

Esto quiere decir que cada iteración del producto es únicamente una primera hipótesis que podría cambiar en base al feedback de los usuarios.

Medición del producto en cada iteración

Además de las entrevistas de usuario, podemos también medir con productos como Amplitude la efectividad de la funcionalidad, y ver que puntos del flujo podrían mejorarse en la siguiente iteración de producto.

Esto quiere decir que cada iteración del producto permite entender mejor cómo interactuan nuestros clientes con la funcionalidad, y en base a este análisis, podremos ver puntos de fuga de funnel y mejorar dichas métrica.

Conclusiones

Poder mapear las historias de usuario de una iniciativa te permite ver el flujo por el que irá el usuario que use tu producto, y también le permitirá a tu equipo ver cómo encajan todas las historias de usuario unas con otras, y en que release se sacará cada parte del código.

Si además invitas a tu equipo a entrevistas de usuario cuando prueben el producto en cada iteración, ellos también podrán entender si las siguientes iteraciones tienen sentido o si es necesario pivotar en base al feedback de los clientes.

El mapeo de historias de usuario es tremendamente efectivo y divertido de hacer, pero si no lo pruebas nunca lo sabrás. Por eso que te invito a que te “tires a la piscina” y pruebes esta técnica con tu equipo de producto y veas si te funciona.

Por último, te dejo aquí 2 enlaces por si quieres profundizar más en la técnica de mapeo de historias de usuario:

• Mapping User Stories in Agile, artículo de Nielsen Norman Group

• User Story Mapping, libro de Jeff Patton