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

Dieciséis ejemplos de historias de usuario sobre autenticación, comercio electrónico, dispositivos móviles, API y errores; cada uno de ellos viene acompañado de comentarios, y las versiones incorrectas aparecen junto a sus versiones revisadas para que se pueda apreciar la diferencia.

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 va acompañado de 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 el formato en sí es nuevo para usted, empiece por ¿qué es una historia de usuario? — en resumen, todas las historias aquí 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 papel 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 subjetivas. Obsérvese 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 dice 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.

He aquí una persona, un momento y una ventaja que alguien podría sopesar frente a otros trabajos.

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 cambie de opinión.

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 quiere que todos los compradores tengan una cuenta, ese debate se lleva a cabo 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, de modo que pueda completar el proceso de pago con una sola mano.

La tarea épica se convierte en una acumulación de fragmentos como este, cada uno de ellos comprobable y lo suficientemente pequeño como para poder gestionarlo.

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 sin conexión; los técnicos de campo, en cambio, la viven en primera persona. Cuando alguien pregunta «¿hasta qué punto significa “sin conexión”?» durante la fase de perfeccionamiento, el puesto de trabajo ya ha dado la respuesta: 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 tamaño.

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 la API, deseo recibir una respuesta 429 con un encabezado «Retry-After» cuando alcance el límite de frecuencia, 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 en 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 protagonista es el equipo, el objetivo es una actividad en lugar de un resultado, y el término «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 «Cuando 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 conste 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 comporta como cualquier otra historia: se le asignan criterios, un tamaño y un espacio en el sprint. El trabajo específico en la corrección de errores garantiza que la velocidad refleje fielmente a dónde se destina realmente la capacidad; el capítulo sobre puntos de historia expone este argumento en 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 del tipo «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 un spike: investigar durante dos días, comunicar 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 el 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 beneficio 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 cuentas.

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 poder tener una visión general.

Por qué no es válido: «todo» no es un ámbito y la «visibilidad» no es un resultado; nada de lo aquí expuesto puede desarrollarse, probarse ni cuantificarse. 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), de modo que pueda 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á listo.

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 contiene 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 estimación detectan las historias defectuosas más rápidamente que cualquier directriz de redacción: una amplia dispersión en los votos es el mensaje de error de este formato. Redacte su próximo lote siguiendo la plantilla, luego preséntelas al equipo mediante planning poker y observe 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, 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 realiza, 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 relevante es «el equipo», prescinda de la terminología 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 beneficios. 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, seguida de 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