Llevas 10 minutos con una historia de usuario y no te sale el "Para". ¿Qué te está diciendo eso?

Que probablemente esa funcionalidad sobra: si no tiene propósito, no hay que construirla. El Para es la parte más difícil y la más importante: dota de propósito a la funcionalidad y permite validarla después. Si no eres capaz de responder para qué sirve, muy probablemente no es algo que haya que hacer. Somos (de momento) imbatibles razonando: úsalo antes de gastar en construir.

El equipo tiene 9 ideas y 10 minutos. ¿Cómo eliges sin abrir un debate eterno?

Dot voting: cada persona reparte 3 puntos entre las ideas (o los concentra) y gana la más votada. El dot voting llega a consenso en un minuto dando el mismo peso a todos, sin que decida quien más habla. En clase lo usamos para elegir la app médica entre 9 ideas. Ojo: para decisiones de calado (la línea de negocio de una empresa) sí conviene dar espacio a defender cada opción antes de votar.

¿Cuál de estas historias de usuario está bien planteada?

"Como señora María, quiero recibir periódicamente mi insulina para tratar mi enfermedad crónica sin preocuparme del stock." El rol siempre es una persona con una necesidad, no un servidor ni un KPI. La gracia de la historia de usuario es que tu madre la entienda y el equipo técnico también: todos debatiendo en el mismo plano. Ni jerga técnica (cron, base de datos) ni jerga de negocio (EBITDA).

Ya está el mapa montado. ¿Qué es la línea horizontal que lo cruza?

Separa el MVP (lo mínimo para lanzar sintiéndote cómodo) de las siguientes releases. Lo de abajo no se pierde: espera su turno. La línea se traza debatiendo historia a historia: ¿es esencial para lanzar? Encima queda el producto mínimo viable (tu roadmap inmediato); debajo, las siguientes releases. Después el mapa se verticaliza en un backlog: una lista única con lo más importante arriba.

User Story Map, de la idea al MVP co-creando

La sesión en la que votamos una idea con dot voting, definimos tres buyer persona, montamos la espina dorsal de actividades y acciones, escribimos historias de usuario con sus criterios de aceptación y trazamos la línea del MVP. Todo en un Miro compartido, y de postre: un prototipo generado con IA a partir del mapa.

Empezar el repaso

00 Repaso
01 Qué problema resuelve el mapa
02 Dot voting: consenso en un minuto
03 Conoce a tu usuario: 4 preguntas
04 Actividades y acciones: la espina dorsal
05 Historias de usuario: Como, Quiero, Para
06 Criterios de aceptación y Gherkin
07 La línea del MVP
08 Del mapa al prototipo con IA
09 Tu plan de acción
★ Imprescindibles

User Story Map

Técnica de gestión visual propuesta por Jeff Patton: mapear el flujo del usuario en actividades y acciones, colgar debajo las historias de usuario y trazar la línea del MVP. El mapa es el roadmap visual del producto.
Ver en el diccionario
Dot voting

Votación con puntos: cada participante reparte 3 votos entre las opciones (o los concentra en una). Consenso en un minuto sin abrir debate. Así elegimos la idea de la clase.
Ver en el diccionario
Buyer persona

Arquetipo de tu usuario ideal construido con 4 preguntas: quién es, qué desea, qué necesidad le resolvemos y cómo prefiere interactuar. Pone al usuario en el centro antes de construir nada.
Ver en el diccionario
Historia de usuario

Convención para definir una funcionalidad sin lenguaje técnico ni jerga de negocio: Como [persona], Quiero [necesidad], Para [propósito]. Si tu madre no la entiende, está mal escrita.
Ver en el diccionario
Criterios de aceptación

Las condiciones que deben cumplirse sí o sí para dar por buena una historia de usuario: límites, reglas de negocio, requisitos técnicos. En lenguaje natural o en Gherkin.
Ver en el diccionario
Gherkin

Formato estructurado para criterios de aceptación: Dado [contexto], Cuando [evento], Entonces [resultado]. Permite testear: si el flujo no se cumple, la funcionalidad no está terminada.
Ver en el diccionario
MVP

Producto mínimo viable: la versión con las funcionalidades mínimas necesarias para salir al mercado y validar, sin volverse loco con el roadmap completo. En el mapa, todo lo que queda encima de la línea.
Ver en el diccionario
Backlog

Lista única ordenada verticalmente donde el mapa se aplana al final: lo más importante arriba, lo menos abajo. Da foco al equipo durante el desarrollo.
Ver en el diccionario
Roadmap

La hoja de ruta del producto. En el User Story Map no es un documento aparte: lo que queda por encima de la línea del MVP es tu roadmap, visual y debatido por todo el equipo.
Ver en el diccionario

Glosario

User Story Map: Técnica de gestión visual propuesta por Jeff Patton: mapear el flujo del usuario en actividades y acciones, colgar debajo las historias de usuario y trazar la línea del MVP. El mapa es el roadmap visual del producto.
Dot voting: Votación con puntos: cada participante reparte 3 votos entre las opciones (o los concentra en una). Consenso en un minuto sin abrir debate. Así elegimos la idea de la clase.
Buyer persona: Arquetipo de tu usuario ideal construido con 4 preguntas: quién es, qué desea, qué necesidad le resolvemos y cómo prefiere interactuar. Pone al usuario en el centro antes de construir nada.
Historia de usuario: Convención para definir una funcionalidad sin lenguaje técnico ni jerga de negocio: Como [persona], Quiero [necesidad], Para [propósito]. Si tu madre no la entiende, está mal escrita.
Criterios de aceptación: Las condiciones que deben cumplirse sí o sí para dar por buena una historia de usuario: límites, reglas de negocio, requisitos técnicos. En lenguaje natural o en Gherkin.
Gherkin: Formato estructurado para criterios de aceptación: Dado [contexto], Cuando [evento], Entonces [resultado]. Permite testear: si el flujo no se cumple, la funcionalidad no está terminada.
MVP: Producto mínimo viable: la versión con las funcionalidades mínimas necesarias para salir al mercado y validar, sin volverse loco con el roadmap completo. En el mapa, todo lo que queda encima de la línea.
Backlog: Lista única ordenada verticalmente donde el mapa se aplana al final: lo más importante arriba, lo menos abajo. Da foco al equipo durante el desarrollo.
Roadmap: La hoja de ruta del producto. En el User Story Map no es un documento aparte: lo que queda por encima de la línea del MVP es tu roadmap, visual y debatido por todo el equipo.

Repaso

Repaso rápido de la sesión

Antes de bucear en los recursos, comprueba qué se te ha quedado: recordar de forma activa fija mucho más que releer. No hay nota ni castigo, y si fallas te explico el porqué.

Repaso · Pregunta 1/5

"Registro" y "validar el email", ¿qué son en el mapa?

Las dos son historias de usuario. Registro es una actividad (bloque grande) y validar el email es una acción (concreta, verbo en infinitivo) que vive dentro de ella. Las dos son actividades del mismo nivel.

"Registro" y "validar el email", ¿qué son en el mapa?
- Las dos son historias de usuario.
- Registro es una actividad (bloque grande) y validar el email es una acción (concreta, verbo en infinitivo) que vive dentro de ella.(respuesta)
- Las dos son actividades del mismo nivel.
Las actividades son los grandes bloques de la espina dorsal (registro, compra, pago, atención médica); las acciones son cosas concretas que suelen empezar con verbo en infinitivo (ver la pantalla de bienvenida, validar el email). La frontera es debatible y es normal que al principio salgan mezcladas: el propio diálogo para distinguirlas ya genera entendimiento compartido.
Llevas 10 minutos con una historia de usuario y no te sale el "Para". ¿Qué te está diciendo eso?
- Que hay que escribirla en Gherkin, que es más fácil.
- Que necesitas más tiempo: el propósito siempre acaba saliendo.
- Que probablemente esa funcionalidad sobra: si no tiene propósito, no hay que construirla.(respuesta)
El Para es la parte más difícil y la más importante: dota de propósito a la funcionalidad y permite validarla después. Si no eres capaz de responder para qué sirve, muy probablemente no es algo que haya que hacer. Somos (de momento) imbatibles razonando: úsalo antes de gastar en construir.
El equipo tiene 9 ideas y 10 minutos. ¿Cómo eliges sin abrir un debate eterno?
- Decide el jefe, que para eso es el jefe.
- Dot voting: cada persona reparte 3 puntos entre las ideas (o los concentra) y gana la más votada.(respuesta)
- Se discute cada idea 15 minutos y luego se vota a mano alzada.
El dot voting llega a consenso en un minuto dando el mismo peso a todos, sin que decida quien más habla. En clase lo usamos para elegir la app médica entre 9 ideas. Ojo: para decisiones de calado (la línea de negocio de una empresa) sí conviene dar espacio a defender cada opción antes de votar.
¿Cuál de estas historias de usuario está bien planteada?
- "Como servidor, quiero recibir las solicitudes de la API para modificar la base de datos."
- "Como señora María, quiero recibir periódicamente mi insulina para tratar mi enfermedad crónica sin preocuparme del stock."(respuesta)
- "Como negocio, queremos subir el EBITDA un 300% con delivery integral."
El rol siempre es una persona con una necesidad, no un servidor ni un KPI. La gracia de la historia de usuario es que tu madre la entienda y el equipo técnico también: todos debatiendo en el mismo plano. Ni jerga técnica (cron, base de datos) ni jerga de negocio (EBITDA).
Ya está el mapa montado. ¿Qué es la línea horizontal que lo cruza?
- Separa las actividades de las acciones.
- Separa el MVP (lo mínimo para lanzar sintiéndote cómodo) de las siguientes releases. Lo de abajo no se pierde: espera su turno.(respuesta)
- Separa lo que hace el equipo técnico de lo que hace producto.
La línea se traza debatiendo historia a historia: ¿es esencial para lanzar? Encima queda el producto mínimo viable (tu roadmap inmediato); debajo, las siguientes releases. Después el mapa se verticaliza en un backlog: una lista única con lo más importante arriba.

Qué problema resuelve el User Story Map

~4 min

Cuando un equipo va a crear un producto digital, los tropiezos son casi siempre los mismos tres. Jeff Patton propuso el User Story Map precisamente para resolverlos con gestión visual: en lugar de documentación extensiva y Exceles, un mapa que todo el equipo construye y ve a la vez.

Las tres problemáticas de siempre

01 Entendimiento compartido
Que "la app debería tener esta funcionalidad" signifique lo mismo para todo el grupo. Sin acuerdo sobre el qué, cada uno construye una película distinta en su cabeza.
02 Priorizar
Distinguir lo importante de lo urgente y de lo esencial. Cuando todo parece importante, nada es importante.
03 Definir el alcance
Saber cuándo el producto está lo bastante maduro para salir al mercado sin dañar tu reputación, y sin esperar a tener el roadmap completo. Ese fino equilibrio es el MVP.

El Tinder de mascotas (o por qué no basta con 'tener la idea')

"Nos piden crear el Tinder de mascotas." ¿Qué es? ¿Qué funcionalidades tiene? ¿Cómo hace login el usuario, qué flujo sigue desde que se descarga la app hasta que sale de ella? Responder a eso en un documento de 40 páginas no genera acuerdo: genera un documento que nadie lee. El mapa pone esas mismas preguntas en la pared, con el usuario en el centro, y el acuerdo se construye pegando post-its y debatiendo en el mismo plano.

En la vida real esta dinámica dura días, no una hora y media: antes de invertir dos millones en construir algo, tómate al menos un par de semanas en definirlo.

Dot voting: consenso en un minuto

~3 min

Para arrancar hace falta una semilla: una idea. En clase cada uno propuso la suya en un post-it (plataformas de salud, apps de ganadería, servicios de handyman...) y elegimos por dot voting: tres puntos por persona, repártelos como quieras (los tres a una idea o repartidos). Ganó la app de servicios médicos: agendar consultas, atención a la tercera edad, historial médico y envío de medicamentos.

Cuándo usarlo: el dot voting llega a consenso sin abrir un debate enorme ni escuchar todas las opiniones una a una, y da el mismo peso a todos. Para una dinámica de clase, perfecto tal cual; para decidir la línea de negocio de una empresa, da antes espacio a que cada idea se defienda, y luego vota.

Conoce a tu usuario: cuatro preguntas

~6 min

Antes de hablar de funcionalidades, hay que saber para quién construimos. No hace falta un buyer persona de manual: bastan cuatro preguntas. Quién es (datos demográficos), qué desea, qué necesidad le resolvemos y cómo prefiere interactuar. Esta última se olvida siempre y condiciona todo: he visto equipos enteros construyendo una app Android para descubrir que su usuario quería una web, o apostando por gafas VR que su usuaria no tiene ni quiere tener.

Lucía · 56 · Panamá

Gerente de mercadeo, ingresos medio-altos. Su madre de 85 años vive en Venezuela.

Desea: cuidar a su madre a distancia
Necesita: enviarle insumos médicos a casa y gestionar asistencia a domicilio
Interactúa: app móvil

Señora María · 85 · Venezuela

Pensionista. La usuaria final del servicio, pero no del móvil.

Desea: atención integral de salud cuando la necesite
Necesita: urgencias, atención primaria, clínicas con convenio
Interactúa: llamada telefónica, no una app

Alejandro · 50 · Venezuela

Dueño de la mejor cadena de farmacias. Ingresos altos.

Desea: innovar en un mercado estancado
Necesita: vender online, cobros internacionales, control de stock
Interactúa: ordenador; el delivery se delega o lo hace su farmacia

Por qué importa

Fíjate en la señora María: la app es para ella, pero ella no quiere una app, quiere un teléfono al que llamar. Ese matiz (que salió co-creando, no lo tenía nadie en la cabeza) cambia el producto entero: la hija gestiona desde el móvil, la madre recibe el servicio por voz. Y no hay que resolver todas las necesidades de todos los persona: mejor una o dos bien resueltas que un frankenstein de funcionalidades.

Actividades y acciones: la espina dorsal

~6 min

El esqueleto del mapa es el flujo del usuario de punta a punta: desde que descarga la aplicación hasta que recibe los medicamentos en casa. Ese flujo se construye con dos niveles, y pasar de lo general a lo concreto es exactamente el objetivo del mapa:

Actividades

Los bloques grandes

Lo que responderías si alguien pregunta "¿qué tiene tu aplicación?": registro, compra, pago, atención médica, postventa.

Cada actividad agrupa acciones. "Trabajamos el registro" significa trabajar todo lo que cuelga de esa columna.

Acciones

Lo concreto, en infinitivo

Cosas específicas que suelen empezar con verbo en infinitivo: ver la pantalla de bienvenida, validar el email, filtrar clínicas, programar la reposición del medicamento.

¿Esto es actividad o acción? Ese debate es normal, no hay un método exacto: el propio diálogo para decidirlo ya está generando entendimiento compartido.

Por qué importa

En clase, del caos de post-its salieron columnas que nadie había planificado: registro de datos (historial médico, coberturas, direcciones), compra (con suscripción de tratamientos crónicos), pago, atención médica (filtro de clínicas, citas a domicilio, llamada de urgencia), perfil de farmacias y postventa. Y una lección de producto: nos habíamos olvidado de Alejandro (la farmacia), y sin farmacias no hay usuarios ni viceversa. El núcleo de valor a veces está en el actor que nadie mapeó.

Historias de usuario: Como, Quiero, Para

~7 min

Para bajar el mapa a funcionalidades usamos la convención que técnica y negocio hemos pactado: la historia de usuario. Tres palabras: Como (un rol, siempre una persona), Quiero (la necesidad) y Para (el propósito).

La historia de la insulina

"Como señora María, quiero recibir periódicamente mi medicación para la diabetes cada mes, para tratar mi enfermedad crónica sin preocuparme del stock."

Con esa frase mi madre entiende qué vamos a construir, y el equipo técnico también. Compárala con "un cron que consulta la tabla Petition y cruza stock de farmacias" (mi madre fuera) o con "aumentar el EBITDA un 300% con delivery integral" (todos fuera). La historia de usuario pone a todo el mundo a debatir en el mismo plano.

Nada de "como servidor, quiero recibir solicitudes de la API": el rol es una persona con nombre. Es quien tiene la necesidad.

El Para es el filtro: es la parte que más cuesta y la más importante. Si no consigues escribir el propósito de una funcionalidad, probablemente esa funcionalidad no hay que hacerla. "Quiero los medicamentos en realidad aumentada en el metaverso... ¿para?" Exacto: fuera.

Criterios de aceptación: natural o Gherkin

~6 min

Si solo das el Como-Quiero-Para, el equipo decide libremente el cómo. Cuando hay requisitos que deben cumplirse sí o sí, se explicitan como criterios de aceptación (y de paso le pones un título a la historia, que leerla entera cada vez cansa: "Suscripción de medicamento").

Lenguaje natural

Escribes la regla y listo. Aquí va todo lo que no le dirías a tu madre: límites, reglas de negocio, detalles técnicos.

El periodo máximo de suscripción es de 36 meses
Se puede cancelar hasta 48 horas antes de la entrega
Antes de enviar la medicación, notificaremos a la hija por push

Gherkin: Dado / Cuando / Entonces

El mismo criterio como flujo estructurado. La ventaja: se puede testear. Si el flujo no se cumple, no está terminado.

DADO una suscripción de medicamento mensual
CUANDO se esté preparando para su envío
ENTONCES la usuaria y sus familiares reciben una notificación push

Por qué importa

Gherkin viene del ecosistema de testing (Cucumber) y es la versión sofisticada; el lenguaje natural es perfectamente válido. En clase el grupo clavó los dos a la primera, incluido un "dado la ausencia de medicamentos en el país, cuando se acerque el periodo de solicitud, entonces alertar por la aplicación o correo". Eso ya es pensar en producto.

La línea del MVP: el mapa es el roadmap

~5 min

Último movimiento: cada historia se hace pequeñita y se cuelga debajo de la actividad y acción que le corresponde. Con el mapa ordenado, se traza una línea horizontal debatiendo historia a historia: ¿es esencial para lanzar? Encima queda el MVP: lo mínimo que necesitas para salir al mercado sintiéndote cómodo. Debajo, las siguientes releases: nada se pierde, solo ocupa otro lugar en la prioridad.

Y después del mapa: lo que queda arriba es tu roadmap visual. Cuando toca ejecutar, el mapa se verticaliza en un backlog: una lista única con lo más importante arriba y lo menos abajo, que da foco al equipo durante el desarrollo.

Del mapa al prototipo con IA

~5 min

El cierre moderno de la sesión: con la idea, los tres persona y el mapa definidos, se lo damos todo a una IA (en clase, Google AI Studio) y en minutos tenemos un prototipo navegable con una pantalla por persona: la interfaz simplificada con botón de "llamar ahora" para María, la gestión del historial y las citas para Lucía, el stock y los tratamientos crónicos para Alejandro. ¿Feo? Bastante. ¿Suficiente para validar la hipótesis con usuarios reales? Totalmente.

El prompt del mapa · pégalo con tu USM en AI Studio, Claude o la IA que uses

ACTÚA COMO un equipo de producto y diseño que convierte
definiciones en prototipos navegables.

RESULTADO ESPERADO:
Un prototipo funcional (HTML interactivo) de la aplicación descrita,
con una pantalla por cada buyer persona y sus flujos principales.

CONTEXTO:
- Idea: (pega aquí la idea votada, ej. "app de servicios médicos
  a distancia: agendar consultas, urgencias, envío de medicamentos")
- Buyer personas: (pega aquí tus personas: quién es, qué desea,
  qué necesidad le resolvemos, cómo prefiere interactuar)
- User Story Map: (pega aquí actividades, acciones e historias
  de usuario con sus criterios de aceptación, tal cual del Miro)
- MVP: (lista solo lo que quedó por encima de la línea)

NO QUIERO (GUARDARRAÍL):
- No añadas funcionalidades que no estén en el mapa.
- No inventes datos (precios, teléfonos, medicamentos): usa
  placeholders y pregúntame.
- Prioriza los flujos del MVP; lo demás ni lo dibujes.

Por qué importa

Hay dos maneras de usar la IA: dejar que invente (las riendas las tiene ella, y te "sorprende") o darle definición y que ejecute lo que el equipo ya acordó. Todo lo que hicimos en la sesión (votar, definir personas, mapear, escribir historias) es la manera de domar a la IA: el prototipo sale de vuestro acuerdo, no de su imaginación. Hace un año esta parte de la clase no existía; el estado del arte manda.

Recursos

Web Google AI Studio · la IA que usamos en clase para generar el prototipo a partir del mapa: pega el prompt y deja que construya.
Web Miro · la pizarra virtual de la sesión: post-its, votación con puntos y el mapa colaborativo. Seguís teniendo acceso a la pizarra de clase.
Lectura Story Mapping, por Jeff Patton · la guía del propio autor de la técnica, con plantillas y ejemplos.

User Story Mapping Jeff Patton El libro de referencia de la técnica. Tiene más de 10 años (no esperes la parte de IA), pero sigue siendo la mejor guía para facilitar la sesión, poner a las personas de acuerdo y convertir el resultado en una hoja de ruta. Ver en Amazon →

Tu plan de acción

~2 min

Facilita tu primer User Story Map

La técnica se aprende facilitándola. Marca lo que vayas completando; se guarda en tu navegador.

0/8 completado

Elige una idea (tuya o del equipo) y valídala con dot voting: 3 puntos por persona
Define 2-3 buyer persona con las 4 preguntas: quién es, qué desea, qué le resolvemos, cómo interactúa
Monta la espina dorsal: actividades arriba, acciones debajo, siguiendo el flujo del usuario
Escribe al menos 5 historias de usuario (Como / Quiero / Para) y ponles título
Añade criterios de aceptación a las 2 más importantes (prueba una en Gherkin)
Cuelga las historias bajo su actividad y traza la línea del MVP debatiendo en equipo
Pega el mapa completo en una IA con el prompt de la clase y genera el prototipo
Enseña el prototipo a 3 usuarios potenciales: ¿la necesidad existe? ¿esto la resuelve?

Glosario · toca para ampliar

User Story Map

Técnica de gestión visual propuesta por Jeff Patton: mapear el flujo del usuario en actividades y acciones, colgar debajo las historias de usuario y trazar la línea del MVP. El mapa es el roadmap visual del producto.
Ver en el diccionario
Dot voting

Votación con puntos: cada participante reparte 3 votos entre las opciones (o los concentra en una). Consenso en un minuto sin abrir debate. Así elegimos la idea de la clase.
Ver en el diccionario
Buyer persona

Arquetipo de tu usuario ideal construido con 4 preguntas: quién es, qué desea, qué necesidad le resolvemos y cómo prefiere interactuar. Pone al usuario en el centro antes de construir nada.
Ver en el diccionario
Historia de usuario

Convención para definir una funcionalidad sin lenguaje técnico ni jerga de negocio: Como [persona], Quiero [necesidad], Para [propósito]. Si tu madre no la entiende, está mal escrita.
Ver en el diccionario
Criterios de aceptación

Las condiciones que deben cumplirse sí o sí para dar por buena una historia de usuario: límites, reglas de negocio, requisitos técnicos. En lenguaje natural o en Gherkin.
Ver en el diccionario
Gherkin

Formato estructurado para criterios de aceptación: Dado [contexto], Cuando [evento], Entonces [resultado]. Permite testear: si el flujo no se cumple, la funcionalidad no está terminada.
Ver en el diccionario
MVP

Producto mínimo viable: la versión con las funcionalidades mínimas necesarias para salir al mercado y validar, sin volverse loco con el roadmap completo. En el mapa, todo lo que queda encima de la línea.
Ver en el diccionario
Backlog

Lista única ordenada verticalmente donde el mapa se aplana al final: lo más importante arriba, lo menos abajo. Da foco al equipo durante el desarrollo.
Ver en el diccionario
Roadmap

La hoja de ruta del producto. En el User Story Map no es un documento aparte: lo que queda por encima de la línea del MVP es tu roadmap, visual y debatido por todo el equipo.
Ver en el diccionario

Si solo tienes tiempo para 2 cosas

Si te llevaras únicamente dos cosas de toda esta página, que sean éstas:

El Para es el filtro: una historia de usuario sin propósito es una funcionalidad que sobra. Como [persona], Quiero [necesidad], Para [propósito], y el rol siempre es una persona, nunca un servidor ni un KPI.
Define antes de construir: idea votada, personas con las 4 preguntas, espina dorsal, historias y línea del MVP. Con eso, el prompt de la clase convierte el mapa en un prototipo navegable para validar la hipótesis antes de invertir un euro en desarrollo.

Para cualquier duda, pueden escribirme a hi@alci.dev o por LinkedIn. Y la pizarra de Miro de la sesión sigue disponible para repasar.

Glosario

User Story Map: Técnica de gestión visual propuesta por Jeff Patton: mapear el flujo del usuario en actividades y acciones, colgar debajo las historias de usuario y trazar la línea del MVP. El mapa es el roadmap visual del producto.
Dot voting: Votación con puntos: cada participante reparte 3 votos entre las opciones (o los concentra en una). Consenso en un minuto sin abrir debate. Así elegimos la idea de la clase.
Buyer persona: Arquetipo de tu usuario ideal construido con 4 preguntas: quién es, qué desea, qué necesidad le resolvemos y cómo prefiere interactuar. Pone al usuario en el centro antes de construir nada.
Historia de usuario: Convención para definir una funcionalidad sin lenguaje técnico ni jerga de negocio: Como [persona], Quiero [necesidad], Para [propósito]. Si tu madre no la entiende, está mal escrita.
Criterios de aceptación: Las condiciones que deben cumplirse sí o sí para dar por buena una historia de usuario: límites, reglas de negocio, requisitos técnicos. En lenguaje natural o en Gherkin.
Gherkin: Formato estructurado para criterios de aceptación: Dado [contexto], Cuando [evento], Entonces [resultado]. Permite testear: si el flujo no se cumple, la funcionalidad no está terminada.
MVP: Producto mínimo viable: la versión con las funcionalidades mínimas necesarias para salir al mercado y validar, sin volverse loco con el roadmap completo. En el mapa, todo lo que queda encima de la línea.
Backlog: Lista única ordenada verticalmente donde el mapa se aplana al final: lo más importante arriba, lo menos abajo. Da foco al equipo durante el desarrollo.
Roadmap: La hoja de ruta del producto. En el User Story Map no es un documento aparte: lo que queda por encima de la línea del MVP es tu roadmap, visual y debatido por todo el equipo.