Historias de Usuario, INVEST y Planning Poker
El equipo de EventoUAB salió del kickoff con una lista de ideas crudas: reservar un espacio, ver disponibilidad, cancelar, notificar, iniciar sesión. Esta guía convierte esas ideas en historias de usuario bien formadas, con criterios de aceptación verificables, y les enseña a estimarlas juntos con Planning Poker antes del primer Sprint Planning.
Bienvenido
En el Sprint 0 el equipo de EventoUAB armó un Product Backlog crudo, sin pulir a propósito. Ahora, antes del primer Sprint Planning, toca convertir esas ideas sueltas en historias de usuario: enunciados cortos, con un formato que obliga a nombrar quién se beneficia y por qué, más criterios concretos para saber cuándo están terminadas.
Al finalizar esta guía sabrás escribir una historia en el formato estándar, redactar criterios de aceptación verificables, revisar una historia contra las seis letras de INVEST, priorizar por valor y esfuerzo teniendo en cuenta dependencias, y participar en una sesión de Planning Poker.
Encontrarás actividades cortas y autocorregibles —selección múltiple, clasificación, emparejamiento y completar espacios— repartidas a lo largo de la guía, y una sección de ejercicios de razonamiento donde se te da un escenario y debes predecir la respuesta correcta antes de comprobarla.
✍️ Formato
De "reservar un espacio" a una historia con usuario, acción y beneficio explícitos.
✅ INVEST
Seis preguntas para saber si una historia está lista para entrar a un sprint.
🃏 Planning Poker
Cómo el equipo estima tamaño relativo sin que el primero en hablar arrastre a los demás.
El formato de una historia
Una historia de usuario no es una especificación técnica: es un recordatorio de una conversación pendiente, escrito desde el punto de vista de quien se beneficia. El formato más usado tiene tres partes.
El primer espacio en blanco obliga a nombrar a alguien real, no "el sistema". El tercero obliga a explicar el para qué — si no podés completarlo, probablemente la idea es una tarea técnica disfrazada de historia.
Ejemplo real del backlog de EventoUAB: la idea cruda "reservar un espacio" se convierte en:
Convertí estas dos ideas crudas del backlog al formato de historia.
1. Idea cruda: "cancelar una reserva". Como , quiero , para .
2. Idea cruda: "ver qué espacios están libres". Como , quiero , para .
Criterios de aceptación
Una historia sin criterios de aceptación es una promesa ambigua: cada quien en el equipo se imagina un "terminado" distinto. Los criterios son condiciones concretas y verificables, típicamente en formato Dado / Cuando / Entonces.
Dado que el espacio está libre en ese horario, cuando el estudiante confirma la reserva, entonces el espacio queda marcado como ocupado y aparece en "mis reservas".
Dado que el espacio ya está reservado en ese horario, cuando otro estudiante intenta reservarlo, entonces el sistema muestra que no está disponible y no permite duplicar la reserva.
Los criterios de aceptación describen comportamiento desde afuera, sin mencionar clases ni funciones. Cuando en la guía de Testing armes casos normales, inválidos y de borde, vas a partir exactamente de estos criterios.
¿Cuál de estas opciones es un criterio de aceptación bien escrito para la historia "reservar un espacio"?
INVEST: seis preguntas antes de aceptar una historia
INVEST es un acrónimo con seis propiedades que una buena historia debería cumplir. No es una fórmula mágica — es una lista de chequeo para detectar historias problemáticas antes de que entren a un sprint.
| Letra | Exige que la historia sea... | Ejemplo que la rompe en EventoUAB |
|---|---|---|
| Independent | No depender de forma rígida de otra historia para poder empezarla. | "Reservar un espacio" solo puede arrancar cuando otro equipo termine de migrar el servidor. |
| Negotiable | Un punto de partida para conversar, no un contrato cerrado con todos los detalles técnicos fijos. | "Reservar un espacio usando exactamente este componente de calendario con esta paleta de colores." |
| Valuable | Aportar valor visible al usuario, no ser una tarea técnica interna disfrazada. | "Como desarrollador, quiero refactorizar la clase Reserva." |
| Estimable | Estar lo bastante clara como para que el equipo pueda estimar su tamaño. | "Como usuario, quiero que el sistema sea seguro." |
| Small | Caber cómoda en un solo sprint. | "Como estudiante, quiero gestionar completamente mi club: eventos, miembros, presupuesto y reservas." |
| Testable | Poder verificarse objetivamente si se cumplió o no. | "Como usuario, quiero que la app sea intuitiva." |
¿Qué letra de INVEST rompe principalmente cada historia?
Valor, esfuerzo y dependencias
Con el backlog convertido en historias, hay que ordenarlas. La regla práctica: comparar el valor que aportan contra el esfuerzo que cuestan, y revisar si alguna depende técnicamente de otra.
| Valor | Esfuerzo | Qué hacer |
|---|---|---|
| Alto | Bajo | Primero: gana rápido y visible. |
| Alto | Alto | Vale la pena, pero conviene partirla en historias más chicas. |
| Bajo | Bajo | Relleno oportunista si sobra tiempo en el sprint, no prioridad. |
| Bajo | Alto | Cuestionar si de verdad hace falta, o postergarla. |
Una historia de bajo valor pero que es prerrequisito técnico de otra de alto valor puede tener que ir antes igual. Priorizar por valor no significa ignorar el orden técnico obligatorio.
El equipo tiene tres historias para el Sprint 1: A) ver espacios disponibles en una lista simple — alto valor, esfuerzo chico; B) reservas recurrentes automáticas con reglas complejas — alto valor, esfuerzo grande; C) cambiar la paleta de colores del botón de reservar — bajo valor, esfuerzo chico. El sprint tiene que ser pequeño y mostrable. ¿Cuál entra primero?
Planning Poker
Planning Poker es una forma de estimar el tamaño relativo de una historia entre todo el equipo, sin que la opinión de la primera persona en hablar arrastre a las demás. Cada integrante tiene cartas con una secuencia parecida a Fibonacci: 1, 2, 3, 5, 8, 13, 20, 40, 100.
La distancia entre 7 y 8 casi no importa, pero discutir cuál de los dos es "más correcto" hace perder tiempo. Los saltos grandes (13 a 20, 20 a 40) reflejan que, a mayor tamaño, también crece la incertidumbre real sobre cuánto va a costar.
| Paso | Qué pasa |
|---|---|
| 1. Lectura | El Product Owner lee la historia y sus criterios de aceptación en voz alta. |
| 2. Voto en secreto | Cada integrante elige una carta sin mostrarla todavía. |
| 3. Revelación | Todas las cartas se muestran a la vez. |
| 4. Discusión de outliers | Si hay mucha diferencia (ej. un 2 y un 13), quienes votaron los extremos explican por qué. |
| 5. Nueva votación | Con lo discutido, el equipo vuelve a votar hasta converger. |
Une cada paso de Planning Poker con el motivo por el que existe.
Ejercicios de razonamiento
En estas preguntas no se te pide recordar una definición: se te da un escenario y debés razonar la respuesta antes de comprobarla.
El equipo tiene dos historias: "Como estudiante, quiero reservar un espacio" y "Como estudiante, quiero recibir un correo cuando mi reserva es confirmada".
¿Qué implica esto para el orden del Sprint 1?
Una historia dice: "Como estudiante, quiero administrar todo lo relacionado a mi club: eventos, miembros, presupuesto, reservas y reportes." El equipo no logra estimarla con confianza.
¿Cuál es la forma correcta de partirla, sin perder el criterio INVEST?
Actividades de repaso
Un repaso integrador de todo el módulo. Cada actividad se corrige al instante; tu progreso se guarda automáticamente en este navegador.
¿Por qué el formato "Como... quiero... para..." incluye siempre un "para qué"?
Una historia que cumple INVEST ya no necesita criterios de aceptación, porque el formato "Como... quiero... para..." alcanza.
En Planning Poker, ¿qué señala una diferencia grande entre las cartas reveladas (por ejemplo, un 2 y un 13)?
Una historia de alto valor pero muy grande para caber en un sprint. Según lo visto en esta guía, ¿qué corresponde hacer?
Cheat Sheet
| Término | Idea clave |
|---|---|
| Historia de usuario | "Como <usuario>, quiero <acción>, para <beneficio>." Un recordatorio de conversación, no una especificación cerrada. |
| Criterios de aceptación | Condiciones concretas y verificables (Dado/Cuando/Entonces) que dicen cuándo la historia está terminada. |
| INVEST | Independent, Negotiable, Valuable, Estimable, Small, Testable — seis chequeos para una historia lista. |
| Valor vs. esfuerzo | Alto valor + bajo esfuerzo va primero. Las dependencias técnicas mandan sobre el valor. |
| Planning Poker | Voto en secreto con cartas tipo Fibonacci; se discuten los desacuerdos grandes antes de revotar. |
¿Sabías que...?
✍️ El formato "Como... quiero... para..." tiene autora
Se popularizó como "Connextra template", por la empresa londinense donde Rachel Davies lo propuso en 2001, para que los requisitos dejaran de leerse como listas técnicas y empezaran a nombrar a un usuario real.
🔤 INVEST lo acuñó Bill Wake en 2003
El consultor ágil Bill Wake publicó el acrónimo en su blog como una lista de chequeo rápida, pensada para que un equipo pudiera revisar una historia en segundos, no como una teoría formal.
🧭 Lo que viene en la próxima guía
Con historias priorizadas y estimadas, el próximo paso es modelar el alcance del Sprint 1 con un diagrama de casos de uso: actores, flujos principales y su trazabilidad hacia estas mismas historias.