Ejemplos de historias de usuario: 16 historias comentadas, buenas y malas

Dieciséis ejemplos de historias de usuario, extraídos de los ámbitos en los que trabajan realmente los equipos: autenticación, comercio electrónico, dispositivos móviles, API, errores y herramientas internas. Cada uno de ellos incluye comentarios: no solo qué dice la historia, sino también por qué las cláusulas de «función» y «beneficio» son imprescindibles. Cuatro de ellas son deliberadamente deficientes y se muestran junto a sus versiones revisadas, ya que la forma más rápida de aprender el formato es observar cómo falla.

Si este formato le resulta nuevo, comience por preguntarse: «¿Qué es una historia de usuario?». En resumen, todas las historias siguen el formato «Como [rol], quiero [objetivo], para que [beneficio]», y cualquier historia bien redactada podría pasar directamente a la fase de refinamiento y a una ronda de «planning poker».

Autenticación y cuentas

1. Iniciar sesión

Como cliente habitual, deseo iniciar sesión con mi correo electrónico y mi contraseña para poder consultar mi historial de pedidos.

Por qué funciona: el rol es específico. «Cliente habitual» le indica que esta persona tiene una cuenta, ha realizado pedidos anteriormente y tiene un motivo para volver: tres datos que un diseñador y un evaluador pueden aprovechar. «Como usuario» no habría aportado ninguno de ellos.

2. Restablecimiento de la contraseña

Como usuario que no puede acceder a su cuenta, deseo restablecer mi contraseña desde la pantalla de inicio de sesión, para poder volver a acceder a mi cuenta sin tener que ponerme en contacto con el servicio de asistencia.

Por qué funciona: la cláusula de beneficios menciona un coste real. Cada restablecimiento que pasa por el servicio de asistencia supone un coste cuantificable, por lo que esta incidencia puede priorizarse frente a otras basándose en datos concretos y no en impresiones. Observe lo que la frase no incluye: la caducidad de los tokens, los límites de frecuencia ni la plantilla de correo electrónico. Esos detalles deben figurar en los criterios de aceptación, que se redactarán cuando el equipo los perfeccione:

• En un plazo de dos minutos tras la solicitud, recibirá un correo electrónico para restablecer la contraseña.
• El enlace de restablecimiento caduca al cabo de una hora y solo se puede utilizar una vez.
• El formulario ofrece la misma respuesta tanto si la dirección de correo electrónico existe como si no (sin enumeración de cuentas).

3. La historia circular

Como usuario, deseo iniciar sesión para poder acceder a la aplicación.

Por qué no es válido: se han rellenado todos los campos, pero no se ha dicho nada. El «papel» es «nadie en concreto», y el «beneficio» se limita a reiterar el objetivo, por lo que la cláusula «para que» podría eliminarse sin que se pierda información. Una historia como esta supera la comprobación de formato, pero omite todo el razonamiento que dicho formato pretende exigir.

La nueva redacción:

Como miembro del proyecto que regresa a mitad de un sprint, deseo acceder directamente al tablero que estaba viendo la última vez que inicié sesión, para no tener que volver a buscarlo cada mañana.

Ahora bien, hay una persona, un momento y una ventaja que alguien podría sopesar frente a otro trabajo.

Comercio electrónico

4. Persistencia del carrito

Como comprador que navega por la web durante mi pausa para comer, quiero que mi carrito conserve los artículos cuando vuelva esta noche, para no tener que volver a buscarlos todos.

Por qué funciona: el rol incluye un contexto. «Navegar por la web durante la pausa para comer» explica por qué se abandonan los carritos a mitad del proceso, lo que indica al equipo que el plazo de persistencia relevante se mide en horas, no en segundos. Un rol bien elegido permite transmitir el contexto en una sola cláusula.

5. Finalización de la compra como invitado

Como es la primera vez que compro, deseo realizar el pago sin crear una cuenta, para poder finalizar mi compra antes de que me lo piense mejor.

Por qué funciona: parte de una propuesta de valor del producto (las cuentas son opcionales) y expone el beneficio de forma sincera: las dudas frenan las primeras compras. Las explicaciones tan claras como esta también sacan a la luz los desacuerdos desde el principio: si la empresa desea que todos los compradores tengan una cuenta, ese debate se abordará durante la fase de perfeccionamiento, no en la solicitud de incorporación de cambios.

6. El personaje que lleva un disfraz de cuento

Como comprador, deseo un proceso de pago más rápido y sencillo, para que mejore la tasa de conversión.

Por qué no funciona: por dos motivos. «Más rápido, más limpio» no es una capacidad que cualquiera pueda desarrollar o probar, y «la conversión mejora» es un beneficio para la empresa, no para el comprador. Ningún comprador desea la conversión. Se trata del trabajo de todo un trimestre condensado en una sola frase, lo que lo convierte en una epopeya, no en una historia.

La reescritura (un fragmento de la misma):

Como comprador que realiza la compra desde el móvil, deseo que mi dirección de envío se rellene automáticamente a partir de mi código postal, para poder completar el proceso de pago con una sola mano.

La tarea épica se convierte en una lista de tareas pendientes compuestas por partes como esta, cada una de ellas verificable y lo suficientemente pequeña como para poder gestionarla.

Móvil

7. Modo sin conexión

Como técnico de campo, deseo que la hoja de trabajo de hoy se cargue sin necesidad de conexión, para poder seguir trabajando en sótanos y zonas sin cobertura.

Por qué funciona: el puesto de trabajo determina el requisito. El personal de oficina nunca se percata de la asistencia fuera de línea; los técnicos de campo, en cambio, la viven en primera persona. Cuando alguien pregunta «¿hasta qué punto significa “fuera de línea”?» durante la fase de perfeccionamiento, el puesto de trabajo ya ha respondido: allá donde les lleve el trabajo.

8. Preferencias de notificación

Como suscriptor que recibe tres notificaciones push al día, deseo poder elegir qué tipos de alertas me envían notificaciones, para no tener que silenciar toda la aplicación.

Por qué funciona: el beneficio identifica el modo de fallo que la historia evita. Los usuarios no se quejan del volumen de las notificaciones; simplemente silencian la aplicación y se marchan sin decir nada. Una historia que identifique el comportamiento silencioso contra el que se defiende es una historia sobre la que el equipo puede debatir con franqueza.

API y trabajo técnico

9. Paginación

Como desarrollador de integración, deseo que las respuestas del punto final /events estén paginadas, para que mi sincronización nocturna no agote el tiempo de espera en cuentas de gran volumen.

Por qué funciona: esta es la historia de usuario técnica legítima: el desarrollador es un usuario real y externo con sus propios objetivos, no el equipo que se incluye a sí mismo en la frase. Los usuarios de la API, los autores de complementos y los operadores de guardia superan todos esa prueba.

10. Limitación de la tasa

Como usuario de una API, deseo recibir una respuesta 429 con un encabezado «Retry-After» cuando alcance el límite de solicitudes, de modo que mi cliente pueda reducir la frecuencia de las solicitudes en lugar de que falle toda la tarea.

Por qué funciona: el objetivo es lo suficientemente preciso como para constituir por sí mismo el primer criterio de aceptación, y sigue siendo un qué, no un cómo: nada de lo aquí expuesto determina la implementación del limitador.

11. La refactorización encubierta

Como desarrollador, deseo refactorizar el módulo de pagos para que el código resulte más claro.

Por qué no funciona: el papel es el equipo, el objetivo es una actividad en lugar de un resultado, y «más limpio» no se puede comprobar. Se trata del formato de historia aplicado a un contexto para el que no fue diseñado, un caso que se aborda en el artículo «Cuándo las historias de usuario no son la herramienta adecuada».

La reescritura (no es una historia de usuario, a propósito):

Reducir la dependencia del módulo de pagos respecto a los proveedores, de modo que se pueda añadir un nuevo proveedor de pagos sin modificar el proceso de pago principal. Se considerará completada cuando: se haya extraído la interfaz del proveedor, los dos proveedores existentes funcionen a través de ella y el conjunto de pruebas de integración se supere sin modificaciones.

Un tema técnico sencillo con un resultado concreto siempre es mejor que una historia llena de adornos.

¿Es un error o una función?

12. El error que es una historia

Como cliente con un plan anual, deseo que en mi factura figure el descuento que se me indicó, para que el departamento de finanzas pueda conciliarla sin necesidad de abrir un ticket de asistencia.

Por qué funciona: se conoce la causa y la solución tiene un alcance claro, por lo que esto se gestiona como cualquier otra historia: se le asignan criterios, un tamaño y un espacio en el sprint. El trabajo en los errores puntuales garantiza que la velocidad refleje fielmente a dónde se destina realmente la capacidad; en el capítulo sobre los puntos de historia se expone este argumento con todo detalle.

13. El error que no lo es

Hay clientes que, de forma esporádica, informan de que se les ha cobrado dos veces. No se ha podido reproducir el problema de forma fiable.

Por qué no es una historia: no hay margen para hacer promesas. Una frase de «rol-objetivo-beneficio» («Como cliente, quiero que no se me cobre dos veces…») sería cierta pero inútil, y cualquier estimación no sería más que una mera esperanza. Lo más adecuado es realizar una prueba rápida con un plazo limitado: investigar durante dos días, presentar lo aprendido y, a continuación, redactar la historia real para la corrección.

Herramientas internas y elaboración de informes

14. Herramientas de apoyo

Como agente de atención al cliente en un chat en directo, deseo ver los últimos cinco intentos de inicio de sesión del cliente, para poder distinguir de un solo vistazo si se trata de una contraseña olvidada o de una cuenta bloqueada.

Por qué funciona: los usuarios internos siguen siendo usuarios. La ventaja se mide en segundos por ticket, que es precisamente el tipo de interés concreto que permite que esta tarea compita con el trabajo de atención al cliente por un hueco en el sprint, en lugar de quedar descartada por defecto.

15. Exportaciones

Como jefe de equipo, deseo exportar el informe del sprint en formato CSV para poder compartir los resultados con las partes interesadas que no disponen de cuenta.

Por qué funciona: la cláusula «para que» delimita sutilmente el alcance del trabajo. Compartir fuera de la herramienta es la tarea en sí, lo que descarta soluciones como los paneles de control integrados en la aplicación y las reglas en un aburrido archivo CSV portátil. Una buena cláusula de beneficio realiza el trabajo de diseño de forma gratuita.

16. La epopeya de la visibilidad

Como responsable, deseo disponer de un panel de control que refleje todo lo que está haciendo el equipo, para tener una visión general.

Por qué no es válido: «todo» no es un ámbito y la «visibilidad» no es un resultado: aquí no hay nada que se pueda desarrollar, probar o cuantificar. Detrás de una historia como esta se esconde una pregunta real que aún no se le ha planteado al responsable.

La nueva redacción:

Como responsable de entrega encargado de preparar la reunión de estado del lunes, deseo tener en una sola página el objetivo del sprint de cada equipo y su estado (rojo, ámbar o verde), para poder señalar el trabajo bloqueado sin tener que contactar con cada responsable.

La misma persona, el mismo instinto, pero ahora se adapta a un sprint y el probador sabe cuándo está terminado.

Lo que tienen en común los mejores

Repase los doce que funcionan. Cada uno de ellos nombra a una persona lo suficientemente concreta como para tener una opinión, establece un objetivo que esa persona reconocería y aporta un beneficio que resiste un «¿por qué?» sincero. Ninguno de ellos incluye detalles de implementación, y ninguno pretende ser exhaustivo. Para eso están los criterios de aceptación y la conversación de refinamiento.

Las cuatro historias defectuosas fallan exactamente de dos maneras, lo cual resulta alentador: o bien el beneficio es circular (nadie ha comprobado el porqué) o bien el alcance es una «épica» (nadie ha comprobado su magnitud). Ambos fallos salen a la luz en el momento en que su equipo intenta estimar la historia, razón por la cual las sesiones de dimensionamiento detectan las historias defectuosas más rápidamente que cualquier directriz de redacción: una amplia dispersión en la votación es el mensaje de error del formato. Redacte su próximo lote siguiendo la plantilla y, a continuación, preséntelo al equipo mediante el «planning poker» para ver cuáles convergen.

Preguntas frecuentes

¿Cuál es un ejemplo de historia de usuario?

«Como cliente habitual, deseo iniciar sesión con mi correo electrónico y mi contraseña para poder consultar mi historial de pedidos». En ella se menciona a una persona concreta, una capacidad desde el punto de vista de dicha persona y el motivo por el que merece la pena programar esa tarea. Esa estructura de tres partes (función, objetivo y beneficio) constituye el formato clásico de una historia de usuario.

¿Cómo se redacta una buena historia de usuario?

Indique un rol concreto en lugar de «un usuario», defina el objetivo como algo que la persona hace, en lugar de algo que contiene el sistema, y complete la cláusula «para que» con un beneficio que resista un «¿por qué?» sincero. A continuación, añada los criterios de aceptación, ya que la frase de la historia es un punto de partida para la conversación, no el requisito en sí.

¿Se puede redactar un trabajo técnico en forma de historia de usuario?

A veces. Si el «usuario» es real (un desarrollador de integraciones que utiliza su API, un operador de guardia), el formato funciona tal y como está redactado. Si el único rol auténtico es «el equipo», prescinda de la forma y redacte un elemento técnico sencillo con un resultado concreto y criterios de aceptación. La disciplina se mantiene; la estructura de la frase no tiene por qué hacerlo.

¿Deberían redactarse los errores como historias de usuario?

Un error cuya causa se conoce y cuya solución es clara puede ser objeto de una historia, y señalarlo garantiza la veracidad de la velocidad. Un error que nadie puede reproducir no puede serlo: no hay margen para hacer promesas, por lo que una historia no sería más que una suposición con una cláusula de beneficio. Establezca primero un plazo para la investigación y, a continuación, redacte la historia real en función de lo que se descubra.

¿Qué nivel de detalle debe tener una historia de usuario?

Una frase que resuma la historia y, a continuación, entre tres y cinco criterios de aceptación. La frase da pie a la conversación; los criterios recogen lo que se ha acordado en dicha conversación. Si la lista de criterios sigue creciendo hasta superar los cinco, la historia se convierte en varias historias, y los criterios le indican dónde debe dividirla.

Lecturas relacionadas

• Estimación ágil: la guía completa. Aquí encontrará toda la información al respecto.
• ¿Qué es una historia de usuario? El formato, las tres «C» y la lista de verificación INVEST que subyace a cada uno de los ejemplos anteriores.
• Plantilla de historia de usuario y criterios de aceptación. Una plantilla para copiar y pegar y un ejemplo práctico que incluye la estimación.
• División de historias de usuario. Qué hacer con las «épicas» que se ocultan en los ejemplos 6 y 16.
• Ejemplos de estimación ágil. La serie complementaria: cómo se percibe realmente la estimación de estas historias en la sala.