El desarrollo de un producto puede volverse complejo muy rápidamente si no nos ocupamos de pensar en cómo organizar todas las tareas que deben realizarse para lograr un primer lanzamiento y definir los siguientes. Organización que, al trabajar en equipos multidisciplinares, debe ser clara y entendible.

El User Story Mapping es una herramienta muy popular en equipos de producto que busca ubicar todas las piezas necesarias para la elaboración de un producto usable, con el fin de asegurar un desarrollo ordenado del proyecto y mantener a todo el equipo alineado sobre lo que se realizó previamente, lo que se esta realizando ahora y lo que se realizará más adelante.

El propósito de este artículo es brindar una breve introducción por la herramienta, su finalidad, componentes, como elaborarla y algunas prácticas a evitar. Sin nada más por agregar, ¡comencemos! 🚀

‍

¿Qué es y por qué?

Jeff Patton, un importante consultor sobre temas relacionados a Producto, introdujo por primera vez el concepto allá por el año 2005, aunque no sería hasta el año 2008 que paso a ser conocido como User Story Mapping. Todas sus ideas sobre esta novedosa forma de llevar a cabo el desarrollo de un producto fueron organizadas en un libro muy recomendado titulado con el nombre de la herramienta, lanzado en 2014.

‍

‍

En simples palabras, el User Story Mapping es una herramienta para organizar el trabajo a realizar por el equipo de desarrollo. Básicamente consiste en plantear todos los requerimientos a desarrollar y repartirlos a lo largo del flujo de experiencia del cliente. El desarrollo se organiza esencialmente de dos maneras:

• Horizontal: se reparten los distintos requerimientos necesarios para elaborar el producto en torno a las diferentes tareas que el usuario debe realizar para alcanzar su objetivo, ordenadas por la secuencia lógica en la que suceden.l
• Vertical: se establecen grupos de historias de usuarios que van a componer las distintos releases o lanzamientos que se hagan a lo largo del desarrollo de producto. Es decir, exactamente en que estaremos trabajando en cada iteración del producto que lancemos.

Esta disposición nos permite ver qué funcionalidades vamos a estar desarrollando para cada tarea que el usuario debe realizar en la plataforma, y además entender que vamos a estar desarrollando primero y qué haremos después.

‍

‍

En Producto, por lo general los requerimientos son redactados en la forma de User Stories (o historias de usuario). Este formato permite la redacción de funcionalidades desde el punto de vista del usuario, especificando qué usuario debe realizar qué tarea, y por qué. Por esta razón, decimos que trabajamos sobre “historias” en lugar de “requerimientos”.

La confección de un User Story Map sigue tres beneficios principales:

• 🎯 Alineación: se busca alinear a toda la empresa en torno a cómo se construye producto y qué es exactamente lo que vamos a estar elaborando, para que todos entiendan el proceso y el enfoque que tendrá, y así mejorar la comunicación.
• 👁️ Previsibilidad: se otorga previsibilidad a todo el equipo sobre qué es lo que hicimos, qué es lo que debemos hacer ahora, y cuáles serán los próximos pasos y la dirección que tomaremos en torno al desarrollo. Establecemos compromisos y dejamos en claro que cuestiones quedan libres de compromiso. Se esclarece qué es lo que se estará entregando en diferentes lanzamientos.
• ⚠️ Administración de riesgos: la herramienta otorga la posibilidad de administrar y visibilizar los riesgos de una forma más conveniente. Podemos comprender si estamos realmente enfrentando los principales riesgos al principio del desarrollo, o si lo estamos dejando para el final.
• ‍

¿Cómo se compone?

El primer contacto visual con la herramienta puede ser un poco abrumador. Es que si bien su propósito y objetivo es simple de entender, la cantidad de elementos que lo componen pueden intimidar un poco. Esta es la razón por la cual vamos a repasar los principales componentes que tiene un Story Map.

‍

‍

Usuario: el propósito de la herramienta es ordenar los distintos requerimientos funcionales en torno a la experiencia del usuario. Entonces, como todo gira en torno al mismo, se debe determinar qué usuario exactamente consideraremos para el armado de User Story Map. En este apartado, se puede elaborar y compartir un arquetipo de persona, donde establecemos las principales metas del usuario con el producto, así como también sus frustraciones y algunas características sobre su comportamiento. Determinar el usuario es importante para establecer un foco temprano. Además este es el primer paso, ya que luego en base al usuario se desglosarán las actividades. 👤

Actividades: las actividades son esencialmente categorías que reúnen tareas similares que nuestro usuario estará realizando en su experiencia utilizando el producto. Son etapas o fases, bloques temáticos, que sirven para dar mayor contexto a las tareas que la componen. Por ejemplo, podemos dividir la experiencia de la compra de un libro en las siguientes categorías: Búsqueda, Compra y Entrega. Y dentro de la categoría Búsqueda, podemos pensar en tareas cómo: Ingresar a categoría, Filtrar resultados, Comparar productos similares y Seleccionar producto.

Backbone/tareas: la serie de las distintas tareas que el usuario va a a realizar para poder alcanzar su objetivo en tu producto componen al flujo narrativo, o backbone. Las tareas están ordenadas en base a una secuencia lógica que el usuario promedio tomará, y las mismas determinan la cantidad de columnas que tendrá nuestro Story Map. Debajo de estas tareas, se detallarán todas las historias de usuario pertinentes a resolver este paso. 🛠️

Historias de usuario: este componente es el corazón de la herramienta. Básicamente un User Story Mapping sin historias de usuario no tiene razón de ser, será un documento vacío. Las historias de usuario son esencialmente requerimientos escritos desde el punto de vista de usuario, y determinan la cantidad y tipo de acciones que el usuario podrá realizar dentro del producto. Por ejemplo, para la tarea “Ingresar a la plataforma”, las distintas historias de usuario pueden referir a:

• Ingresar a través de usuario y contraseña
• Ingresar a través de Facebook
• Ingresar a través de Google
• Crear una nueva cuenta
• Recuperar contraseña en caso de olvidarla

Releases: finalmente, las historias de usuario debe ser organizadas en base a diferentes releases, lanzamientos o versiones. Esto quiere decir que se deben establecer prioridades: determinar qué conjunto de funcionalidades se deben desarrollar primero (la primerísima primer versión se conoce como “Walking Skeleton”), y cuáles luego. Esta es una excelente manera de ubicar las tareas más riesgosas y nuestros supuestos más críticos al comienzo del proceso de desarrollo. De esta forma, visualizamos mejor en qué debemos trabajar primero para asegurar un desarrollo con la menor cantidad de idas y vueltas posible. 📅

‍

¿Cómo creamos un Story Map?

La práctica del User Story Mapping se da en la fase Delivery. Esto implica que es una herramienta para organizar DESARROLLO y no DESCUBRIMIENTO. Por lo que previo a su armado, hay cosas que ya deberíamos tener resueltas o trabajadas. Por ejemplo, debemos saber con certeza:

• Cuáles son nuestros distintos tipos de usuarios a los que podremos atender.
• Cuál es el flujo lógico de tareas que los usuarios realizarán en la plataforma.
• Cuáles serán historias de usuario o requerimientos que debemos elaborar para proveer una solución acorde.

‍

‍

En base a esta información inicial, debemos seleccionar a un usuario determinado entre todos los que tenemos identificados. Por ejemplo, para un marketplace como Uber, podemos decidir trabajar sobre la experiencia del chofer o la experiencia del pasajero, que son muy distintas entre sí. 👥

Una vez establecido un usuario, debemos marcar cuál es su objetivo principal, la meta que quiere lograr o el problema que quiere resolver, y mapear toda la lista de tareas que debería realizar en nuestra plataforma en consecuencia. Esta lista de tareas debería seguir un flujo lógico, una secuencia esperada por la mayor parte de los usuarios. Una vez tengamos la secuencia resuelta, debemos señalar a que actividad o categoría pertenece cada tarea, con el fin de agrupar las distintas acciones que el usuario debe tener en un bloque temático para brindar mayor contexto a cada fase.

¡Genial! Ya seleccionamos un usuario y establecimos el orden lógico de tareas categorizadas que realizará en nuestro producto para alcanzar su objetivo. Ahora debemos tomar todas nuestras historias de usuario y ordenarlas en su columna correspondiente, es decir, en base a las distintas tareas que hemos marcado dentro del flujo narrativo. 💬

Una vez organizamos todas las historias de usuario en sus respectivas tareas, viene la parte más importante: determinar en enfoque de los distintos releases. Cabe destacar que la idea es lanzar incrementos de producto de forma frecuente, por lo que la duración de cada release no debería tomar más de un mes. Dicho esto, la idea es distribuir las historias de usuarios en base a la prioridad y el riesgo que tienen. Decidir que conjunto de historias van a desarrollarse en el primer release, cuales en el segundo, cuales en el tercero, y así sucesivamente. Durante este ejercicio, es probable cometer algunos errores por lo que a continuación veremos algunos casos de User Story Mapping mal aplicados, con el objetivo de mantenernos al margen de algunas prácticas contraproducentes.

‍

Malas aplicaciones de la herramienta

Para asegurar un uso correcto del User Story Mapping, se debe considerar lo siguiente: buscaremos tener una versión mínima del producto o funcionalidad que estamos desarrollando desde el primer release. Esto se conoce como Walking Skeleton. Y luego, en cada lanzamiento, debemos ir completando ese producto en base a cada tarea del usuario. Por ejemplo, para la tarea “Filtrar productos”, para la primera versión podemos desarrollar únicamente la historia de usuario referida a filtrar productos por precio, pero para la segunda versión, podes sumar la capacidad de filtrar productos por color, y así sucesivamente vamos completando cada tarea de forma equitativa en cada release.

Tomando de referencia la imagen que figura debajo, me parece importante que repasemos algunas malas aplicaciones del User Story Mapping:

‍

‍

📍 Arriba/izquierda - Releases muy cargados: cada tarea a lo largo de distintos releases está plagada de historias de usuario. Esto lleva a releases muy largas y distanciadas entre sí. En tal caso se deben planificar releases adicionales para repartir mejor la carga de trabajo y que no queden releases tan pesadas.

📍 Arriba/centro - Poca priorización: En este caso, veamos que cada tarea a lo largo de cada release tiene un número muy similar de historias de usuario. No siempre tiene que ser así. Hay releases donde quizás trabajemos intensamente en algunas tareas y tengamos 4/5 historias de usuario en la misma, mientras en otras historias quizás avanzamos con solo una o dos. Es importante priorizar bien en qué tareas poner el foco para cada release.

📍 Arriba/derecha - Desarrollo en cascada: la idea de cada release es tener una versión incrementada del producto en cada una de las tareas que debe completar el usuario. Debe existir al menos una mínima versión del producto usable partir de la primer versión, y no tener un producto que recién pueda ser usada después de múltiples releases.

📍 Abajo/izquierda - Distribución equitativa: No necesariamente hay que distribuir en partes iguales el número de historias de usuario a lo largo de distintos releases y tareas. Hay releases que serán más complejas que otras, y tareas que en determinadas instancias requerirán más trabajo e historias de usuario que otras.

📍 Abajo/centro - Releases al infinito: la herramienta provee previsibilidad, pero no clarividencia. La idea es tener una referencia aproximada sobre qué vamos a estar trabajando de acá a tres meses, entendiendo que el plan puede ir variando según pasan las semanas (es un documento flexible, nada está escrito en piedra). El User Story Mapping no sirve para planificar el desarrollo de un producto por un año, debido a la inherente incertidumbre que tienen estos tipos de proyectos.

📍 Abajo/derecha - Ausencia de desarrollo en tareas: similar al caso del desarrollo en cascada, en este escenario se dejan tareas sin historias de usuario a desarrollar durante varias releases. La idea del User Story Mapping como se comentó anteriormente es al menos tener una historia de usuario a desarrollar por cada tarea a lo largo de las distintas releases, para generar así un incremento en cada aspecto del producto luego de cada versión.

Espero que hayan podido comprender las cuestiones que el User Story Mapping busca resolver, cuál es su lugar dentro del proceso de desarrollo de producto, cómo se compone esta herramienta y cómo ustedes pueden elaborarla y mantenerse conscientes de las malas aplicaciones. Es una herramienta súper intenta de gran utilidad que seguro les proveerá muchísimas ventajas a la hora de planificar su producto. 🤗

¡Y eso es todo!  Espero que hayan disfrutado el artículo. Me ayudarían mucho en compartirlo con las personas que crean que les será útil. ¡Te aconsejo que te suscribas a Productified para no perderte ninguna novedad!