Guía Agile · Prácticas ágiles
Historias de usuario: cómo redactarlas, con plantillas y ejemplos
Una historia de usuario es una descripción breve y en lenguaje sencillo de algo que necesita un usuario, escrita desde su punto de vista. Recoge quién lo quiere, qué quiere y por qué, y sirve como recordatorio para conversar sobre los detalles en lugar de ser una especificación completa.
Puntos clave
- Una historia de usuario indica quién necesita algo, qué necesita y por qué.
- Los criterios de aceptación hacen que cada historia sea comprobable; la Definición de Terminado se aplica a todas las historias.
- Use INVEST para comprobar la calidad y divida las historias que no quepan en un sprint.
- Las historias son un punto de partida para la conversación, no una especificación completa.
La plantilla de historia de usuario
El formato más habitual es: Como [tipo de usuario], quiero [algún objetivo] para [algún beneficio].
- Quién: un usuario o rol concreto, no «el sistema».
- Qué: el objetivo o la capacidad que necesita, no la solución técnica.
- Por qué: el beneficio, que ayuda al equipo a encontrar la forma más sencilla de entregarlo.
Muchos equipos describen una historia mediante las tres C: la tarjeta (la breve historia escrita), la conversación (el debate que completa los detalles) y la confirmación (los criterios de aceptación que demuestran que está terminada).
Criterios de aceptación
Los criterios de aceptación son las condiciones que una historia debe cumplir para ser aceptada. Hacen que la historia sea comprobable y reducen los malentendidos. Dos estilos habituales:
- Lista de verificación: «La reserva muestra la hora y el lugar de la clase»; «El socio recibe un correo electrónico de confirmación».
- Dado-Cuando-Entonces: «Dado que una clase tiene plazas libres, cuando un socio pulsa Reservar, entonces se reserva una plaza y el número de plazas libres disminuye en una».
La lista de verificación INVEST
| Letra | Significado | Pregunta que hacerse |
|---|---|---|
| I | Independiente | ¿Se puede entregar sin esperar a otra historia? |
| N | Negociable | ¿Los detalles están abiertos a debate en lugar de estar cerrados? |
| V | Valiosa | ¿Aporta valor a un usuario o al negocio? |
| E | Estimable | ¿La entiende el equipo lo bastante bien como para estimarla? |
| S | Pequeña | ¿Se puede terminar dentro de un sprint? |
| T | Comprobable | ¿Tiene criterios de aceptación claros? |
Cómo escribir una historia de usuario, paso a paso
- Identifique al usuario y su objetivo, idealmente a partir de investigación o comentarios reales.
- Escriba la historia con la plantilla, en una o dos frases.
- Añada entre tres y seis criterios de aceptación.
- Coméntela con el equipo durante el refinamiento del backlog y ajústela.
- Compruébela con INVEST; divídala si es demasiado grande.
- Estímela, por ejemplo, con puntos de historia.
- Ordénela en el backlog del producto según el valor, el riesgo y las dependencias.
Ejemplos: deficientes y mejorados
| Historia deficiente | Historia mejorada |
|---|---|
| Como usuario, quiero una tabla de base de datos para las reservas. | Como socio, quiero reservar una clase para que mi plaza quede asegurada. |
| Como sistema, quiero enviar correos electrónicos. | Como socio, quiero un correo electrónico de confirmación de la reserva para tener un registro de mi clase. |
| Como usuario, quiero que el sitio sea rápido. | Como usuario móvil, quiero que el horario cargue en menos de dos segundos para poder reservar desde cualquier lugar. |
| Como administrador, quiero un módulo de informes con 15 informes. | Como gerente del gimnasio, quiero ver la asistencia semanal por clase para poder ajustar el horario. |
Ejemplo completo: Como socio, quiero apuntarme a una lista de espera cuando una clase esté completa para poder conseguir plaza si alguien cancela. Criterios de aceptación: el botón Apuntarse a la lista de espera solo aparece cuando una clase está completa; el socio ve su posición; cuando se libera una plaza, se ofrece por correo electrónico a la primera persona, que dispone de dos horas para aceptarla.
Errores comunes
- Escribir tareas técnicas disfrazadas de historias.
- Historias tan grandes que abarcan varios sprints; trátelas como épicas y divídalas.
- Sin la cláusula «para», lo que oculta la necesidad real.
- Tratar la historia como un contrato en lugar de como el inicio de una conversación.
- Criterios de aceptación ausentes o vagos, que provocan retrabajo.
- Escribir todas las historias con la plantilla incluso cuando una frase sencilla sería más clara.
Plantillas gratuitas sobre este tema
Preguntas frecuentes
¿Qué es una historia de usuario en Agile?
Una breve descripción de una necesidad del usuario, escrita desde su punto de vista, que el equipo convierte en funcionalidad operativa.
¿Cuál es el formato de una historia de usuario?
Como [tipo de usuario], quiero [objetivo] para [beneficio].
¿Quién escribe las historias de usuario?
Cualquiera puede escribirlas, pero normalmente el Product Owner es responsable de que sean claras y estén ordenadas en el backlog.
¿Forman parte de Scrum las historias de usuario?
No. La Guía de Scrum habla de elementos del Product Backlog; las historias de usuario son una forma popular de redactarlos.
¿Qué son los criterios de aceptación en las historias de usuario?
Condiciones específicas y comprobables que una historia debe cumplir para ser aceptada, a menudo escritas como lista de verificación o en formato Dado-Cuando-Entonces.
¿Qué tamaño debe tener una historia de usuario?
Lo bastante pequeña para terminarse dentro de un sprint e, idealmente, en pocos días.
¿Qué significa INVEST en las historias de usuario?
Independiente, Negociable, Valiosa, Estimable, Pequeña (Small) y Comprobable (Testable).
¿Cuál es la diferencia entre una historia de usuario y un requisito?
Un requisito tradicional especifica en detalle lo que debe hacer el sistema; una historia de usuario describe una necesidad e invita a conversar para acordar los detalles. Consulte requisitos del proyecto.
¿Cuál es la diferencia entre una historia de usuario y una épica?
Una épica es un gran bloque de trabajo formado por muchas historias; una historia cabe en un solo sprint.
¿Cómo se estiman las historias de usuario?
La mayoría de los equipos usan estimación relativa, como puntos de historia o tallas de camiseta, acordada por todo el equipo.
¿Se pueden usar historias de usuario fuera del software?
Sí. Los equipos de marketing y otros equipos escriben historias como «Como cliente potencial, quiero una comparación de precios para poder elegir un plan»; consulte marketing ágil.