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

Dieciséis ejemplos de historias de usuario comentadas que abarcan los ámbitos de la autenticación, el comercio electrónico, las aplicaciones móviles, las API y los errores, en los que se muestran las versiones incorrectas junto a sus versiones revisadas para que se aprecie 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 este formato le resulta nuevo, comience 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 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 reinicio que pasa por el servicio de asistencia supone un coste cuantificable, por lo que este caso puede priorizarse frente a otros basándose en pruebas, en lugar de 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 el propio formato pretende exigir.

La nueva redacción:

Como miembro del proyecto que regresa a mitad de un sprint, deseo acceder directamente al panel que estaba consultando 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 un beneficio 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, deseo 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 de la compra 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 desea que todos los compradores tengan una cuenta, ese debate se abordará en la fase de perfeccionamiento, no en la solicitud de incorporación de cambios.

6. La métrica con 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 «mejora la conversión» es un beneficio para la empresa, no para el comprador. Ningún comprador desea la conversión. Se trata de todo el trabajo de un trimestre comprimido 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 lista de tareas pendientes formadas por 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 del soporte fuera de línea; los técnicos de campo, en cambio, lo viven en primera persona. Cuando alguien pregunta «¿hasta qué punto es “fuera de línea” el “fuera de línea”?» 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 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 frecuencia, de modo que mi cliente pueda retrasar la solicitud 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 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 «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 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 trata como cualquier otra historia: se le asignan criterios, un tamaño y una franja en el sprint. La asignación de puntos a los 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 de «función-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 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 un chat en directo, deseo ver los cinco últimos intentos de inicio de sesión del cliente, de modo que pueda 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 y portátil formato CSV. 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 funciona: «todo» no es un ámbito y la «visibilidad» no es un resultado: nada de lo que aquí se plantea 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 de 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 un 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 a un «¿por qué?» sincero. Ninguno de ellos incluye la 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 de 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 sería un ejemplo de una 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 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, adjunte 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 retórica 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 que la velocidad se mantenga realista. 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