Historias de Usuario vs Casos de Uso vs Historias de Trabajo (Ejemplos)

Las historias de usuario, los casos de uso, las historias de trabajo y las declaraciones de requisitos son cuatro formas de escribir qué debe hacer el software. A menudo se presentan como rivales, pero responden a diferentes preguntas en diferentes niveles de detalle. Una historia de usuario pregunta quién quiere qué y por qué. Un caso de uso recorre una interacción paso a paso, incluyendo lo que sale mal. Una historia de trabajo parte de la situación en la que se encuentra el usuario. Un requisito establece una regla que el sistema debe cumplir.

Esta guía compara las cuatro, muestra la misma función escrita de cada forma y explica cuál usar en cada caso. Para lo básico de la escritura de historias, consulta nuestra guía de referencia en cómo escribir historias de usuario.

Comparación rápida

Historias de usuario

Una historia de usuario es una descripción breve de una capacidad, contada desde el punto de vista de la persona que la desea. El formato habitual, “Como [tipo de usuario], quiero [acción], para que [beneficio]”, surgió del equipo de Connextra en 2001 y se difundió a través del libro de Mike Cohn, User Stories Applied. Las historias se desarrollaron en Extreme Programming, donde eran deliberadamente breves: Ron Jeffries describió cada historia como una tarjeta, una conversación y una confirmación (los 3 Cs). La tarjeta no es la especificación; la conversación es donde se acuerdan los detalles, y los criterios de aceptación los confirman.

Fortalezas: las historias son lo suficientemente pequeñas para estimarlas y completarlas en un sprint, son fáciles de leer para los interesados no técnicos y mantienen el valor (“para que”) en el centro de atención. Mike Cohn expone el caso a favor de ellas en Ventajas de las historias de usuario para los requisitos.

Limitaciones: un backlog de historias individuales no muestra cómo encajan juntas en un flujo, y el formato facilita omitir los casos de error. Los equipos resuelven el primero con un mapa de historias de usuario y el segundo con criterios de aceptación bien redactados (ver nuestro plantilla de historias de usuario).

Casos de uso

Un caso de uso describe cómo un actor (una persona o otro sistema) utiliza el sistema para alcanzar un objetivo, como una secuencia de pasos, junto con las formas en que esa secuencia puede ramificarse o fallar. Ivar Jacobson introdujo los casos de uso a finales de los años 80, y el libro de Alistair Cockburn, Writing Effective Use Cases (2000), estableció el estilo centrado en objetivos y en texto plano que la mayoría de los equipos usan hoy en día (Sitio web de Cockburn).

Un caso de uso completo suele incluir:

• Actor principal: quién inicia la interacción.
• Objetivo y alcance: lo que el actor desea y qué sistema se está describiendo.
• Precondiciones: lo que ya debe ser cierto.
• Disparador: lo que inicia el caso de uso.
• Escenario de éxito principal: los pasos numerados cuando todo sale bien.
• Extensiones: rutas alternativas y de fallo, cada una vinculada al paso donde se ramifican.
• Postcondiciones o garantías: lo que es cierto al final, en caso de éxito y en caso de fallo.

Fortalezas: la sección de extensiones obliga a pensar en lo que puede salir mal, y el flujo completo es visible en un solo lugar, lo cual es valioso para integraciones, pagos y cualquier cosa auditada. Limitaciones: los casos de uso tardan más en escribirse y mantenerse actualizados, y un caso de uso suele ser demasiado grande para construirse en un solo sprint.

Los casos de uso se han adaptado al trabajo ágil. En Use-Case 2.0, Jacobson y sus colegas dividen cada caso de uso en “rebanadas”, cada una lo suficientemente pequeña para planificarla y probarla, que cumplen un papel muy similar al de las historias de usuario.

Historias de trabajo (jobs to be done)

Una historia de trabajo reemplaza la persona con la situación: “Cuando [situación], quiero [motivación], para poder [resultado esperado]”. La idea fue mencionada por primera vez por Paul Adams en el blog de Intercom y desarrollada por Alan Klement, quien la explicó en una publicación invitada de Intercom en 2013, Usando historias de trabajo para diseñar funciones. Aplica el pensamiento de jobs-to-be-done, asociado con Clayton Christensen, al diseño de funciones.

El argumento a favor de las historias de trabajo es que “Como un padre ocupado” implica suposiciones que el equipo no puede probar, mientras que la situación (“Cuando estoy a punto de salir de casa y me doy cuenta de que olvidé pedir la compra”) explica la urgencia, las restricciones y cómo se siente el “hecho” para el usuario. Dos personas muy diferentes en la misma situación a menudo necesitan lo mismo.

Fortalezas: las historias de trabajo son buenas en el descubrimiento y el diseño, mantienen al equipo enfocado en el contexto y producen mejores preguntas para las entrevistas con clientes. Limitaciones: dicen poco sobre quién está autorizado a hacer qué, lo cual es importante para permisos y roles, y la mayoría de los equipos aún las convierten en historias de usuario o tareas para la planificación.

Enunciados de requisitos

El formato tradicional es un enunciado numerado: “El sistema bloqueará una cuenta después de cinco intentos de inicio de sesión fallidos”. Las especificaciones de requisitos siguen siendo la norma en industrias reguladas, licitaciones gubernamentales y contratos de precio fijo, y el estándar internacional actual para redactarlas es ISO/IEC/IEEE 29148.

Los equipos ágiles también utilizan enunciados de requisitos, principalmente para requisitos no funcionales (rendimiento, seguridad, disponibilidad, accesibilidad) que se aplican a muchas historias. Estos suelen registrarse una vez, en la definición de hecho o en una breve página de atributos de calidad, en lugar de repetirse en cada historia.

La misma función escrita de las tres formas

Función: en una aplicación de gastos compartidos para compañeros de piso, una persona paga algo y divide el costo con los demás.

Como historia de usuario

Como compañero de piso que pagó una compra compartida, quiero dividir el costo con las personas para las que fue, para que el saldo de todos muestre lo que me deben.

• Puedo elegir qué miembros del grupo comparten el costo; yo estoy incluido por defecto.
• La división por defecto es igual; puedo cambiar a montos exactos o porcentajes.
• La aplicación no guardará una división cuyas partes no sumen el total, e indicará en cuánto se desvía.
• El saldo de cada persona se actualiza en cuanto se guarda el gasto, y reciben una notificación.

Como caso de uso

Caso de uso: Dividir un gasto. Actor principal: Pagador. Precondición: el pagador está autenticado y pertenece a un grupo con al menos otro miembro. Disparador: el pagador elige “Agregar gasto”.

1. El pagador ingresa el monto, una descripción y la fecha.
2. El sistema muestra a los miembros del grupo, con el pagador seleccionado.
3. El pagador selecciona a los miembros que comparten el costo.
4. El sistema propone una división igual y muestra cada parte.
5. El pagador confirma.
6. El sistema guarda el gasto, actualiza cada saldo y notifica a los miembros seleccionados.

• 4a. El pagador cambia a montos exactos o porcentajes: el sistema recalcula a medida que se escribe cada valor.
• 5a. Las partes no suman el total: el sistema bloquea el guardado y muestra la diferencia.
• 6a. El dispositivo está sin conexión: el sistema guarda el gasto localmente, lo marca como pendiente y sincroniza al recuperar la conexión.
• Postcondición en caso de éxito: el gasto se registra una vez, y cada saldo lo refleja. En caso de fallo: no hay cambios en los saldos.

Como historia de trabajo

Cuando acabo de pagar algo en la caja que es en parte para mis compañeros de piso, quiero registrarlo antes de olvidar el monto, para poder ser reembolsado sin tener que perseguir a nadie.

Como enunciados de requisitos

• REQ-1: El sistema debe permitir a un miembro del grupo registrar un gasto con monto, descripción, fecha y pagador.
• REQ-2: El sistema debe permitir al pagador dividir un gasto de forma igual, por montos exactos o por porcentaje.
• REQ-3: El sistema debe rechazar una división cuyas partes no sean iguales al total.
• REQ-4: El sistema debe actualizar todos los saldos afectados en un plazo de dos segundos tras el guardado.

Observa lo que cada versión reveló. La historia de usuario es la más fácil de estimar y planificar. El caso de uso es el único que planteó el caso sin conexión y estableció lo que debe ser cierto si el guardado falla. La historia de trabajo reveló la restricción real, que es la velocidad en la caja; sugiere que la primera pantalla debe pedir el monto y nada más, algo que ninguna de las otras versiones habría sugerido. Los requisitos añadieron un objetivo de rendimiento medible que la historia dejó implícito.

¿Cuál deberías usar?

¿Se pueden combinar?

Sí, y la mayoría de los equipos maduros lo hacen. Una secuencia viable se ve así:

1. Usa historias de trabajo mientras investigas, para capturar situaciones y motivaciones de usuarios reales.
2. Organiza las capacidades resultantes en un mapa de historias como historias de usuario, y elige la primera porción de lanzamiento.
3. Para uno o dos flujos donde el fallo es costoso (pagos, registro, sincronización de datos), escribe un caso de uso ligero para encontrar las extensiones, y luego convierte cada extensión en su propia historia o criterio de aceptación.
4. Registra los requisitos transversales (rendimiento, seguridad, accesibilidad, cumplimiento) una vez, como enunciados numerados o en la definición de hecho.

La regla general: escribe solo lo que el equipo necesita para construir la cosa correcta de forma segura. Un equipo de MVP de tres personas no necesita un documento de requisitos, y una integración bancaria no debería basarse en una sola frase.

Errores comunes

• Escribir casos de uso como guiones de interfaz de usuario (“el usuario hace clic en el botón azul”), lo que vincula el requisito a un diseño que cambiará.
• Escribir historias de usuario sin un “para que”, lo que deja al equipo incapaz de sugerir una solución más simple.
• Tratar una historia de trabajo como una persona disfrazada (“Cuando soy una madre ocupada...”); la situación debe ser un momento, no una identidad.
• Copiar una larga lista de requisitos en un backlog como una historia por línea, lo que produce historias sin usuario y sin valor.
• Usar diferentes formatos en el mismo backlog sin acuerdo sobre cuál es la fuente de verdad.

Preguntas frecuentes

¿No estás seguro de cuánta especificación necesita tu producto? Ayudamos a los fundadores a convertir ideas en un backlog con alcance definido y luego lo construimos en sprints cortos. Ver nuestros planes de desarrollo mensual.