¿Qué es el mapeo de historias en Agile?

User Stories1 1

Agile 101

Mapeo de Historias: Pintar la imagen general de las historias de usuario de su producto

Usted mira fijamente su ordenador portátil. Una larga lista de historias de usuario le devuelve la mirada. Revise algunas, intentando ponerlas en un orden razonable. Reordene constantemente la lista. Ya sea para ver todas las historias relacionadas con la característica A, o para ver las historias más importantes de todas las características. Si es que eso es posible. Una y otra vez, se pierde. Lo que se necesita es un Mapeo de Historias. Veamos cómo crear uno utilizando un Mapeo de Historias, pero primero, vamos a profundizar en lo que son.
Story Mapping1 2

El Mapeo de historias en Ágil

¿Qué es el Mapeo de Historias (de usuarios)?

El Mapeo de Historias o Mapeo de Historias de Usuario es una técnica utilizada en el descubrimiento de productos: esbozar un nuevo producto o una nueva característica para un producto existente.vc El resultado es un Mapeo de Historias: todas las historias de usuario ordenadas en grupos funcionales. Esto le ayuda a no perder de vista el panorama general, a la vez que proporciona todos los detalles de la aplicación en su conjunto.

¿Para qué sirve el Mapeo de Historias?

El objetivo principal del Mapeo de Historias es facilitar el descubrimiento del producto y la priorización del trabajo de desarrollo. Esto se consigue poniendo las actividades y tareas del usuario en un mapa que sirve para mantenerlas en contexto. El Mapeo de Historias siempre muestra cómo encaja cada historia individual en el conjunto de la aplicación. Y esto hace que sea fácil detectar las lagunas y decidir la importancia de una sobre otra.

¿Qué Valores y Principios Ágiles apoya el Mapeo de Historias?

El Mapeo de Historias apoya dos valores del Manifiesto Ágil. «La colaboración con el cliente por encima de la negociación del contrato» y «Responder al cambio por encima de seguir un plan». Los mejores resultados se obtienen cuando se colabora con un (futuro) usuario o con un Experto en la materia. Alguien que está íntimamente familiarizado con el trabajo que su aplicación va a soportar y los problemas que va a resolver. Utilizando el Mapeo de Historias, es fácil responder al cambio. Porque cuando añade una nueva historia de usuario, o cambie o elimine una existente, es fácil detectar qué más hay que añadir, cambiar o eliminar.

¿Quién creó el Mapeo de Historias?

Jeff Patton describió por primera vez el Mapeo de Historias en su artículo “It’s All in How You Slice it” (Todo depende de cómo lo cortes) en 2005, cuando ya llevaba un par de años utilizándolo. Pero entonces no lo llamó Mapeo de Historias. Acuñó ese término en su artículo “The New User Story Backlog Is a Map” (El Nuevo Backlog de Historias de Usuario es un Mapa) en el 2008. También escribió un libro sobre ello: “User Story Mapping: Discover the Whole Story, Build the Right Product” (Mapeo de Historias de Usuarios: Descubra toda la historia, construya el producto adecuado).

¿Por qué utilizar el Mapeo de Historias?

¿Qué problemas resuelve el Mapeo de Historias?

Cuando termine su descubrimiento del producto, es probable que ponga las historias de usuario en el backlog de un tablero Scrum o Kanban. Eso está bien para impulsar el esfuerzo de desarrollo una vez que haya decidido el orden de construcción. Sin embargo, las capacidades de gestión del backlog de estas herramientas se quedan cortas para la gestión de productos y lanzamientos. Simplemente porque el backlog se muestra como una lista larga y plana. El filtrado, etiquetado y coloreado que se puede hacer, ayuda un poco, pero nunca se obtiene la imagen completa. El Mapeo de Historias resuelve esto al organizar las historias de usuario en un diseño simple y útil.

¿Qué (otros) beneficios se obtienen del Mapeo de Historias?

El Mapeo de Historias le proporciona una serie de beneficios directos e indirectos.

  • Todo el mundo puede entender fácilmente la aplicación en su totalidad—generalmente la parte más difícil del desarrollo de software. El Mapa de Historia cuenta la historia de lo que resuelve tu aplicación y cómo lo hace para cualquiera que esté interesado. Todos pueden participar en su creación.
  • Se mantiene el panorama general de la aplicación a la vista— perder el panorama general es una queja común en los equipos ágiles.
  • Elaborar y tener visible un Mapa de Historias fomenta el desarrollo iterativo e incremental.

Tener el panorama general al Alcance de la Mano

  • Le muestra dónde encaja una historia de usuario en todo el sistema de un solo vistazo.
  • Le ayuda a decidir qué construir primero. Un mapa de historias facilita la selección de historias de usuario de diferentes características que, en conjunto, proporcionarán un valor significativo. Esto significa que puedes determinar con confianza el alcance y construir un MVP o una versión útil.
  • significa que puede evitar más fácilmente construir algo que no funcione. No se perderá ni olvidará partes importantes que lo harían inutilizable, como un coche sin frenos. Por ejemplo, porque usted retrasó historias de bajo valor de las que dependen sus historias de alto valor.
  • le permite recorrer el mapa de historias para comprobar si hay lagunas: detecta más fácilmente dónde falta algo.
  • le permite tomar decisiones de priorización teniendo en cuenta el contexto de todo el sistema.
  • significa que se evitará mirar a ciegas en una sola historia de usuario.

Cuando cree un Mapa de Historias físico, obtendrá algunos beneficios más.

  • El mapa se convierte en un punto focal para la colaboración y ayuda a la comprensión compartida.
  • El contexto completo que proporciona el mapa ayuda a dimensionar rápidamente las historias de usuario en relación con las demás.
  • Se pueden añadir pegatinas más pequeñas a las tarjetas de historias de usuario para añadir información adicional o marcar las historias para la iteración actual y la siguiente.

Obstáculos y Errores

Los obstáculos y errores más importantes del mapeo de historias son:

  • Trabajar sin un cliente o alguien íntimamente familiarizado con su trabajo
Es necesario colaborar con alguien que utilice o vaya a utilizar su producto para apoyar su trabajo. Sin su opinión y perspectiva, estará adivinando lo que es importante y lo que proporcionará un valor real. Estará jugando a un juego de aciertos y errores y probablemente desperdiciará el esfuerzo de desarrollo.
  • Sin objetivo, sin problema que resolver

Al trabajar sin un problema que resolver, sin un objetivo que alcanzar, no tienes nada que le guíe en sus decisiones y no tendrá ni idea de cuándo ha terminado. Lo que lleva a desperdiciar el esfuerzo, o al menos a gastarlo en algo en el momento equivocado.

  • No mantener visible el mapa

Fuera de la vista, fuera de la mente. Sin el Mapa de Historias como recordatorio visible del panorama general de su aplicación, es muy fácil desviarse del camino. Al igual que el peligro de perderse en la maleza: quedarse atrapado en los detalles de una sola historia que son irrelevantes para el conjunto. Esto duele aún más, cuando esos detalles requieren más esfuerzo del que merece el valor de la historia.

Aunque es preferible tener un Mapa de Historias físico por las ventajas adicionales que proporciona, con tantos equipos remotos hoy en día, no siempre podrá permitirse ese lujo. Pero aun así puedes mantenerlo muy visible. Por ejemplo, puede tener un monitor grande que muestre el mapa en cada lugar donde haya miembros del equipo.

  • No mantener visible el mapa

¿Cómo crear un Mapa de Historias en 6 pasos (con ejemplos)?

1. Empezar con las Grandes Bloques

Identifique las grandes historias, las amplias actividades de los usuarios que su aplicación debe soportar. Son grandes historias porque tienen muchos pasos. Estos pasos no necesitan tener un orden o flujo de trabajo específico. De hecho, muchas actividades de usuario tienen pasos que un usuario hará en diferentes momentos y en diferentes horarios. Escribe cada actividad en una tarjeta. Ordénelas de forma que tengan sentido para el usuario. Si alguien habla de hacer una actividad y luego otra, organícelas en ese orden. Si las actividades no se hacen una tras otra, simplemente utilice el orden en que el usuario habla de ellas. Eso ayudará a contar la historia de la aplicación a los demás. Digamos que usted está construyendo un sitio de Club de Eventos Divertidos. Los visitantes pueden buscar eventos divertidos a los que unirse. Los miembros pueden unirse y organizar eventos. Y el equipo detrás del sitio actúa como moderador y comprueba si los nuevos eventos están dentro de las directrices. Los grandes bloques de este sitio, las actividades de los usuarios podrían tener este aspecto.
Story Mapping 1

2. Rompiendo sus Bloques

Divida la historia de cada actividad del usuario en historias más pequeñas, las tareas del usuario. Coloque las tareas del usuario bajo la actividad a la que pertenecen y ordénelas en la misma dirección que las actividades y en el orden que tenga sentido para el usuario.

En el caso del Club de Eventos Divertidos, esto se ve así.

User Activities 1 1

Ahora tiene lo que se llama la columna vertebral de su Mapa de Historias.

La mayoría de las tareas del usuario tienen pasos o subtareas independientes. Ponga estas subtareas debajo (si va en horizontal) de la tarea de usuario a la que pertenecen.

Esto se ve así.

Story Mapping Board 48 2

Tanto las tareas de usuario como las subtareas se convierten en las historias de usuario que vas a implementar. Después de todo, un usuario todavía necesita seleccionar un evento de una lista para ver sus detalles o unirse a él inmediatamente..

3. Encuentre los Guijarros que se le Escaparon

Recorra el mapa de principio a fin con otra persona a su lado. Puede ser un usuario, un desarrollador, un probador o cualquier otra persona con interés en la aplicación. Habla de los (tipos de) usuarios de tu aplicación y de cómo están utilizando tu aplicación. Es una especie de depuración de patito de goma para su Mapa de Historias. Y, naturalmente, sacará a la luz cosas que se le han pasado por alto. Ya sea porque se le ocurren a usted o porque su compañero se las señala. Resulta que para el Club de Eventos Divertidos, se nos pasaron bastantes.
Break Down The Story 1
Cuando recorra el mapa con alguien, aproveche para anotar el Mapa de Historias con otra información que escuche. Puntos de dolor en el sistema actual, oportunidades que un usuario ha estado esperando. Casos límite y limitaciones que hay que tener en cuenta. Escríbalos en un adhesivo y péguelos en la tarjeta correspondiente.

4. Ponga sus Guijarros en Línea

No tiene mucho sentido priorizar las actividades de los usuarios. Aparte de las actividades que no se utilizarán a diario, es muy probable que se necesite algo de cada actividad para crear un conjunto que funcione. Así que concéntrese en priorizar las tareas del usuario y las subtareas dentro de cada actividad. La ventaja añadida es que no es necesario pensar en la importancia relativa de las tareas que pertenecen a diferentes actividades. En nuestro ejemplo del Club de Eventos Divertidos, las subtareas ya están en orden de importancia. Un poco de optimización prematura por parte de su autor.

5. Esculpa un Valioso Primer Bloque de Piedra con sus Montones de Guijarros

Seleccione las tareas de cada actividad que sean esenciales para crear una primera versión que funcione de principio a fin, aunque sea de forma muy rudimentaria. Ese es tu MVP, su Producto Mínimo Viable.
1 1

6. Seguir Esculpiendo

Planifique sus siguientes lanzamientos priorizando las tareas restantes. Depende enteramente de usted cómo quiera avanzar.

Puede optar por priorizar las historias de mayor valor de varias o incluso de todas las actividades del usuario. También puede optar por centrarse en una sola actividad y priorizar todas las historias menos las de menor valor.  Y puede que la gente de negocios de su empresa quiera tener en cuenta otros aspectos. Ellos están en la mejor posición para decidir qué características e historias constituyen una buena versión.

En lugar de dibujar líneas entre las historias para marcar cuáles van a las siguientes versiones, también puede reorganizar el mapa para mostrar las versiones como tramos horizontales de historias.

Story Mapping Plan 1 2

Uso del Mapeo de Historias con las Aplicaciones Existentes

El Mapeo de Historias no es sólo para las nuevas aplicaciones. También se puede utilizar para las aplicaciones existentes.

Para ayudarle a entender lo que hace una aplicación y recrear su imagen general para que pueda aprovechar eso cuando avance.

Y, por supuesto, para trazar nuevas características y ponerlas en contexto con la aplicación existente.

Si no puede (no se le permite) construir un Mapa de Historia completo de la aplicación existente primero, al menos consiga todas las actividades de los usuarios existentes.

Esto le dará el contexto para las nuevas características.

Y también le dará un lugar para poner las tareas que necesita añadir o cambiar en las actividades de usuario existentes. Por ejemplo, cuando cree una nueva función para enviar correos electrónicos dirigidos. Tendrá que añadir la selección de varios contactos en la lista de contactos existente. Y probablemente también necesitará añadir algunas capacidades de filtrado adicionales allí.

Conviértase en un Narrador de Historias

¿Recuerda el dolor de tener que priorizar las historias en un backlog largo y plano? ¿Y lo difícil que era explicar la aplicación a otras personas? Ahora ya sabe cómo puede ayudarle el Mapeo de Historias. Para priorizar las historias y montar lanzamientos que ofrezcan un valor significativo. Y a contar la historia de su aplicación tal y como la utilizarán los usuarios. Simplemente recorriendo el Mapa de Historias. Así que, haga feliz a su futuro yo, y aproveche el Mapeo de Historias. En una pared, o con una herramienta digital. Por ejemplo, con el Mapeo de Historias Digité.
Signup

Signup for updates!

[wpforms id=»8824″]

Medha Case Study

¡La vida es buena cuando sus equipos ágiles están sincronizados!

Solicite una demostración personalizada de SwiftEnterprise.

Solicitar demostración