Un backlog plano es una lista ordenada por prioridad. Te dice qué construir a continuación, pero no cómo encajan las piezas entre sí, y facilita lanzar diez funciones pulidas que no suman nada que un usuario pueda completar. Un mapa de historias de usuario corrige eso al disponer las historias a lo largo del viaje que recorre un usuario, para que puedas ver el producto completo y recortar un primer lanzamiento que funcione de principio a fin.
Esta guía cubre cómo construir un mapa de historias, cómo convertir su primera capa en el alcance de un MVP, cómo verificar cada historia con INVEST y los patrones de división que transforman historias grandes en historias de tamaño de sprint. Si necesitas los fundamentos primero, empieza con cómo escribir historias de usuario.
Qué es un mapa de historias de usuario
El mapeo de historias fue introducido por Jeff Patton, primero en un artículo de 2005, “It's all in how you slice it”, y luego en su publicación de 2008 The new user story backlog is a map, y más tarde en su libro User Story Mapping (O'Reilly, 2014). Consulta también sus recursos de mapeo de historias y la entrada del glosario de Agile Alliance.
Un mapa tiene dos direcciones:
- De izquierda a derecha es la narrativa: las grandes actividades por las que pasa un usuario, en orden, y los pasos dentro de cada una. Esta fila superior se llama columna vertebral.
- De arriba a abajo es prioridad y detalle: bajo cada paso se encuentran las historias que lo hacen posible, con las más esenciales en la parte superior y las alternativas, casos límite y funciones deseables debajo.
Las líneas horizontales a través del mapa luego lo dividen en porciones de lanzamiento. Todo lo que está por encima de la primera línea es el primer lanzamiento; debe cubrir cada actividad de la columna vertebral, por mínimo que sea.
Cómo construir un mapa de historias en 6 pasos
Puedes hacerlo en una pared con notas adhesivas o en una pizarra digital. Invita a las personas que decidirán el alcance y a las que lo construirán: producto, diseño, al menos un desarrollador e, idealmente, alguien que hable con los clientes. Un primer mapa para un producto pequeño suele tomar una sesión de trabajo de unas pocas horas.
1. Delimitar el problema
Escribe para quién es el producto, el problema que resuelve y el resultado que te indicará que el primer lanzamiento funcionó. Mantén tres frases en la parte superior del mapa. Cada recorte posterior se evalúa en función de este resultado.
2. Mapear la columna vertebral
Pregunta “¿qué hace el usuario primero y luego qué?” y escribe cada actividad en una tarjeta, de izquierda a derecha. Usa verbos: “Encontrar un paseador”, no “Buscar”. Luego divide cada actividad en pasos. Cuenta la historia en voz alta mientras avanzas; los vacíos se vuelven obvios cuando alguien dice “espera, ¿cómo llegaron aquí?”.
3. Explorar los detalles
Bajo cada paso, añade las historias que lo hacen funcionar: opciones, alternativas, casos de error, necesidades de administración. No filtres todavía. Es aquí donde el mapa se paga a sí mismo, porque la gente nota piezas faltantes cuando puede ver todo el recorrido a la vez.
4. Encontrar el esqueleto andante
El esqueleto andante (un término de Alistair Cockburn) es la versión más delgada del producto que funciona de extremo a extremo. Elige la historia bajo cada paso que un usuario no puede hacer sin ella y muévela a la parte superior. Si algún paso no tiene nada esencial, pregúntate si pertenece a la columna vertebral en absoluto.
5. Dividir los lanzamientos
Dibuja líneas horizontales para agrupar historias en lanzamientos. Da a cada porción un nombre que indique el resultado, como “Los dueños pueden reservar y pagar por un paseo”, en lugar de “Lanzamiento 1”. Cada porción debe ser usable por sí sola y responder a una pregunta que tengas sobre el producto.
6. Planificar la primera porción y mantener el mapa vivo
Escribe criterios de aceptación para las historias de la primera porción (nuestro plantilla de historias de usuario tiene tres formatos), verifica cada una contra INVEST, divide las que sean demasiado grandes y muévelas al backlog del sprint. Mantén el mapa visible y actualízalo después de cada lanzamiento; es una herramienta de planificación, no un resultado de un taller único.
Ejemplo: un mapa de historias para una aplicación de paseos de perros
Aquí hay un mapa condensado para un mercado que conecta a los dueños de perros con paseadores locales. Las columnas son la columna vertebral; cada fila es una porción de lanzamiento.
| Porción | Registro | Encontrar un paseador | Reservar un paseo | Pagar | Durante el paseo | Después del paseo |
|---|---|---|---|---|---|---|
| Esqueleto funcional (MVP) | Registrarse con correo electrónico; añadir un perro | Ver una lista de paseadores aprobados cerca de un código postal | Solicitar un horario; el paseador acepta por correo electrónico | Pagar con tarjeta al reservar | El paseador marca el inicio y el fin del paseo | El propietario recibe un mensaje de resumen |
| Lanzamiento 2 | Iniciar sesión con Google o Apple; varios perros | Filtrar por precio y disponibilidad; perfiles de paseadores con fotos | Aceptar y rechazar dentro de la app; recordatorios | Tarjetas guardadas; reembolso automático al cancelar | Ubicación en vivo en un mapa | Valoraciones y reseñas |
| Más adelante | Códigos de referencia | Paseadores favoritos | Reservas semanales recurrentes | Suscripciones y propinas | Actualizaciones fotográficas durante el paseo | Volver a reservar con un solo toque |
Fíjate en lo que omite el esqueleto: no hay seguimiento en vivo, no hay reseñas, no hay mensajería dentro de la app y la aprobación de paseadores se hace manualmente. Pero un propietario aún puede pasar del registro a un paseo finalizado y pagado, lo cual es suficiente para probar si la gente contratará a un desconocido para pasear a su perro.
Cómo el mapa se convierte en el alcance de un MVP
La parte superior de un buen mapa es el alcance de tu MVP. Usa estas verificaciones antes de comprometerte con él:
- Cubre cada actividad de la columna vertebral. Un producto que permite reservar pero no pagar no es un MVP; es media demostración.
- Sirve a un usuario principal y a un recorrido principal. Los roles secundarios (administradores, socios) reciben lo mínimo necesario para mantener el recorrido en marcha, a menudo una hoja de cálculo o un paso manual.
- Prueba una suposición específica. Escribe la pregunta que responde el fragmento junto a él, por ejemplo “¿Los propietarios pagarán antes de conocer al paseador?”
- Se permite el trabajo manual en segundo plano. Aprobar paseadores manualmente o enviar resúmenes por tu cuenta está bien para los primeros usuarios, y te dice qué vale la pena automatizar.
- Se ajusta a tu presupuesto y plazo. Si no es así, elimina historias dentro de cada columna (divídelas, usando los patrones de abajo) en lugar de eliminar columnas enteras.
Para fundadores sin un cofundador técnico, el mapa también es el documento más útil que puedes entregar a un equipo de desarrollo: muestra el producto completo, el primer lanzamiento y el razonamiento detrás del recorte, en una sola página. Nuestra guía sobre construir un MVP como fundador no técnico cubre qué hacer con él a continuación.
La lista de verificación INVEST
Una vez que las historias están en el mapa, verifica cada una en el primer fragmento contra INVEST, el acrónimo propuesto por Bill Wake en 2003 en INVEST en buenas historias y tareas SMART.
| Letra | Significado | Pregunta a hacer | Si no cumple |
|---|---|---|---|
| I | Independiente | ¿Podemos construir y lanzar esto sin esperar a otra historia? | Combina historias fuertemente acopladas, o divídelas de otra manera para que cada una entregue valor por sí sola |
| N | Negociable | ¿La solución sigue abierta a la discusión? | Elimina el detalle de implementación de la historia; mantenlo en las notas |
| V | Valiosa | ¿Notaría un usuario o el negocio si esto se lanzara? | Combina las tareas técnicas en la historia que sirven |
| E | Estimable | ¿Sabe el equipo lo suficiente para estimarla? | Realiza un spike con límite de tiempo o haz las preguntas que bloquean la estimación |
| S | Pequeña | ¿Encaja cómodamente en un solo sprint? | Divídela con uno de los patrones de abajo |
| T | Probable | ¿Podemos escribir criterios de aceptación que pasen o fallen? | Reemplaza las palabras vagas (“rápido”, “fácil”) con resultados observables |
La independencia es el criterio más difícil de cumplir por completo, y está bien tratarlo como un objetivo en lugar de una regla. Los criterios Pequeña y Probable son los que vale la pena aplicar con rigor.
Cómo dividir historias de usuario
Divide las historias verticalmente: cada pieza debe seguir entregando algo que el usuario pueda ver, a través de cada capa del sistema. Dividir por capas (“construir la base de datos”, “construir la API”, “construir la pantalla”) produce piezas que no entregan nada hasta que las tres estén terminadas, lo que contraría el propósito. Estos patrones, recopilados en la Guía de Humanizing Work para dividir historias de usuario de Richard Lawrence y Peter Green, cubren la mayoría de los casos.
Pasos del flujo de trabajo
Divide un proceso de varios pasos en sus pasos, o construye primero la versión simple de extremo a extremo y añade pasos después. “Reservar un paseo” se convierte en: solicitar un horario; el paseador acepta; el propietario recibe una confirmación. Más adelante: el paseador propone una hora diferente.
Variaciones de reglas de negocio
Si una historia tiene varias reglas, lanza primero la más común. “Reembolsos por cancelación” se convierte en: reembolso completo si se cancela 24 horas antes; reembolso parcial dentro de las 24 horas; sin reembolso después de que comience el paseo.
Variaciones de datos
Comienza con un tipo de datos y añade los demás. “Buscar por ubicación” se convierte en: buscar por código postal; luego por ubicación actual; luego dibujando un área en un mapa.
Primero el camino feliz, luego los caminos no felices
Construye el camino principal de éxito, luego maneja los fallos como historias separadas, ordenadas por su frecuencia y por el daño que causan. “Pagar con tarjeta” se convierte en: pago exitoso; tarjeta rechazada; proveedor de pagos no disponible.
Operaciones
“Gestionar perros” oculta crear, ver, editar y eliminar. A menudo solo se necesitan crear y ver para el primer lanzamiento.
Variaciones de interfaz o plataforma
Lanza primero en una plataforma o un método de entrada. Web antes que móvil, o inglés antes que otros idiomas, si tus primeros usuarios lo permiten.
Primero la versión simple, diferir el rendimiento
Haz que funcione, luego haz que sea rápido. Una lista de paseadores que carga en tres segundos para 50 paseadores está bien para una ciudad piloto; optimiza cuando los números lo justifiquen, como su propia historia.
Spike
Cuando una historia no puede estimarse debido a una incógnita (“¿podemos obtener la ubicación en vivo en segundo plano en ambas plataformas de teléfono?”), separa una investigación corta con límite de tiempo. La salida del spike es conocimiento y una historia mejor dimensionada, no funcionalidad lanzada.
SPIDR: una versión corta para recordar
Mike Cohn agrupa las principales técnicas de división bajo el acrónimo SPIDR: Spikes, Paths, Interfaces, Data y Rules (Cinco formas simples pero poderosas de dividir historias de usuario). Si una historia es demasiado grande y no estás seguro de dónde empezar, recorre las cinco en ese orden.
| Técnica | Dividir por | Ejemplo |
|---|---|---|
| Spikes | Investiga lo desconocido primero | Spike de dos días sobre ubicación en segundo plano antes de estimar el seguimiento en vivo |
| Rutas | Rutas alternativas a través de la historia | Pagar con tarjeta ahora; pagar con cartera después |
| Interfaces | Tipo de dispositivo, navegador o interfaz | Reserva del propietario en web primero, en app móvil después |
| Datos | Tipos o rangos de datos | Un perro por reserva primero; varios perros después |
| Reglas | Reglas de negocio, relajadas al principio | Sin reglas de cancelación en el piloto; política de reembolso como su propia historia |
Errores comunes en el mapeo de historias
- Mapear características en lugar de actividades de usuario. Una columna vertebral de “Inicio de sesión, Panel de control, Ajustes” describe pantallas, no un viaje.
- Construir la primera porción con una sola columna de profundidad. Pulir el registro antes de que exista la reserva te deja sin nada que probar.
- Dejar que el mapa se vuelva demasiado detallado. Si estás escribiendo criterios de aceptación en la pared, has pasado del mapeo a la refinación.
- Mapear sin los desarrolladores en la sala. Las porciones dibujadas sin ellos a menudo ocultan historias costosas en la parte superior.
- Tratar el mapa como terminado. Después de cada lanzamiento, lleva lo que aprendiste al mapa y recorta la siguiente porción.
Para historias bien formadas que puedes adaptar para tu propio mapa, ver nuestro ejemplos de historias de usuario.
Herramientas para el mapeo de historias
Una pared y notas adhesivas siguen siendo lo mejor para la primera sesión con todos en una misma sala. Para equipos remotos, pizarras generales como Miro y FigJam tienen plantillas de mapas de historias, y herramientas dedicadas como StoriesOnBoard sincronizan mapas con rastreadores de backlog. Jira y rastreadores similares pueden mostrar historias agrupadas por épica, lo que te da la columna vertebral, pero normalmente necesitas un plugin o una pizarra para ver las porciones de lanzamiento. Elige la herramienta que tu equipo mantendrá abierta; un mapa que nadie actualiza deja de ser útil en uno o dos sprints.
Preguntas frecuentes
¿Qué es el mapeo de historias de usuario?
Una técnica, introducida por Jeff Patton, para organizar historias de usuario a lo largo del viaje que realiza un usuario (la columna vertebral, de izquierda a derecha) y por prioridad (de arriba a abajo). Las líneas horizontales dividen el mapa en porciones de lanzamiento, para que el equipo pueda planificar lanzamientos que funcionen de principio a fin.
¿Cuál es la diferencia entre un mapa de historias y un backlog de producto?
Un backlog es una lista única ordenada por prioridad. Un mapa de historias muestra las mismas historias en dos dimensiones, por actividad de usuario y por prioridad, para que puedas ver cómo encajan entre sí y si un lanzamiento cubre todo el viaje.
¿Qué es un esqueleto andante?
La versión más delgada de un producto que funciona de principio a fin, con una historia esencial bajo cada paso del viaje. El término proviene de Alistair Cockburn; en un mapa de historias suele ser la primera porción de lanzamiento.
¿Qué significa INVEST?
Independiente, Negociable, Valioso, Estimable, Pequeño y Probable. Bill Wake lo propuso en 2003 como una lista de verificación para buenas historias de usuario.
¿Qué tan pequeña debe ser una historia de usuario?
Lo suficientemente pequeña para que el equipo la termine, pruebe y demuestre dentro de un sprint, e idealmente en unos pocos días. Si una historia toma regularmente un sprint completo, divídela.
¿Qué es SPIDR?
Un conjunto de cinco técnicas de división de historias descritas por Mike Cohn: Picos, Rutas, Interfaces, Datos y Reglas.
¿Quién debe participar en una sesión de mapeo de historias?
Las personas que deciden el alcance y las personas que lo construirán: propietario del producto o fundador, diseñador, al menos un desarrollador, e idealmente alguien que hable con los clientes, como soporte o ventas.
¿Tienes un mapa, o solo una idea, y necesitas construir la primera porción? Podemos ayudarte a definir un alcance de MVP que funcione de principio a fin y a lanzarlo en sprints cortos. Ver nuestros planes de desarrollo mensual.