User Stories vs Use Cases: Definiciones, Plantillas y Cómo Elegir Entre Ellos

Un equipo de fintech con el que trabajé el año pasado pasó tres sprints construyendo una funcionalidad de transferencia de depósito con un solo toque. La user story estuvo en el tablero durante semanas: Como titular de cuenta, quiero mover dinero entre cuentas rápidamente, para no tener que navegar por menús. Se estimó, se refinó, se dividió en subtareas y se entregó a tiempo. Dos días después del lanzamiento, compliance rechazó todo el flujo. El use case que el equipo nunca escribió habría sacado a la luz el problema en el día uno: una transferencia entre cuentas de distintos tipos de titularidad dispara un camino de KYC separado que el diseño ignoró por completo. La story capturó la intención del usuario. No capturó lo que el sistema realmente tenía que hacer, y el equipo pagó por esa brecha con un rollback, una conversación con el regulador y un trimestre de confianza que tuvo que reconstruir. La lección quedó en el post-mortem en una sola frase:

• Las definiciones claras y operativas de cada formato y las plantillas canónicas que hay detrás

• Ejemplos trabajados lado a lado para la misma funcionalidad, más 14 patrones y tropiezos

• Cuándo usar stories, cuándo use cases, cuándo ambos y cómo el análisis de sesiones con IA aterriza ambos

Una user story es una descripción corta y conversacional de una funcionalidad desde la perspectiva del usuario, usando el formato "Como [rol], quiero [acción], para [resultado]". Un use case es un artefacto más largo y estructurado que describe los pasos que un usuario y el sistema toman para lograr un objetivo, incluyendo precondiciones, flujo principal, flujos alternativos y postcondiciones. Ambos describen lo que el sistema hace por el usuario; la diferencia está en granularidad, durabilidad e intención. Los equipos de producto maduros los tratan como complementos, no como competidores, y los equipos más fuertes aterrizan ambos en comportamiento real de usuarios capturado por herramientas como UXCam y su capa de analista con IA Tara AI, en lugar de hacerlo sobre opiniones.

¿Qué es una user story?

Una user story es una declaración corta de intención escrita desde la perspectiva de la persona que va a usar la funcionalidad. El formato fue popularizado por Mike Cohn en User Stories Applied, refinado dentro del equipo Connextra que dio origen a la plantilla canónica "Como, quiero, para", y absorbido por Scrum y el movimiento ágil más amplio durante los primeros años 2000. La intención del formato fue deliberada: la story estaba pensada para ser un marcador de posición para una conversación, no una especificación. El equipo leía la tarjeta, se sentaba junto y resolvía los detalles verbalmente antes de escribir el código.

Ese detalle importa porque explica por qué una buena user story es corta. Si puedes escribir una story de cinco párrafos, has escrito un use case disfrazado de story, y el equipo va a tratar las palabras de la tarjeta como el contrato en lugar de tener la conversación que produce uno real. Cohn fue explícito en esto. Su esquema de las tres C, Card, Conversation, Confirmation, definía una story como una tarjeta que disparaba una conversación y terminaba en una confirmación a través de criterios de aceptación. La tarjeta era la más pequeña de las tres.

Las stories viven dentro del ritmo de trabajo del equipo ágil. Están en el backlog, se refinan durante el grooming, se estiman usando story points o tallas de camiseta y se mueven por el tablero a medida que ingenieros y diseñadores las convierten en comportamiento entregado. Se desarman cuando son demasiado grandes (un product manager las llama epics) y se devuelven al backlog cuando los supuestos resultan equivocados. El artefacto está pensado para ser barato de escribir y barato de tirar.

La razón por la que las stories sobrevivieron a los últimos veinte años de churn de procesos de producto es que coinciden con cómo se comunican realmente los equipos distribuidos. Los ingenieros no leen especificaciones de 12 páginas antes de escribir código. Escanean una tarjeta, le hacen tres preguntas al product manager por Slack, construyen un borrador, lo demuestran e iteran. Las stories formalizan ese ciclo. No son la única forma de planear el trabajo, y como argumentará el resto de este artículo no siempre son la forma correcta, pero para la mayoría de las funcionalidades modernas en ciclos ágiles son la herramienta más liviana que produce buenos resultados.

Algunas observaciones prácticas sobre las stories que la literatura subestima. Primero, las stories funcionan mejor cuando el equipo tiene un product manager fuerte que ha internalizado al usuario. La tarjeta es corta porque el resto del contexto vive en la conversación, y la conversación requiere de una persona que pueda responder preguntas sobre la marcha. Segundo, las stories son más débiles cuando el equipo está genuinamente distribuido a través de zonas horarias sin solapamiento, porque la conversación se colapsa en comentarios asíncronos que terminan leyéndose como un mal use case de todos modos. Tercero, las stories son más débiles aún cuando importan compliance, seguridad o especificaciones contractuales, porque la ausencia de un flujo estructurado se vuelve un pasivo en cualquier auditoría.

¿Qué es un use case?

Un use case es una descripción estructurada de cómo un usuario (u otro actor) interactúa con un sistema para lograr un objetivo. El formato fue popularizado por Alistair Cockburn en Writing Effective Use Cases y antes por Ivar Jacobson durante las eras de Objectory y Rational Unified Process. Los use cases preceden por una década a las user stories y fueron el artefacto de requerimientos dominante en el software empresarial durante los años 90. No han desaparecido. Se han especializado en los contextos donde su estructura justifica su peso.

Un use case tiene partes: un título, un actor primario (y cualquier actor secundario), un conjunto de precondiciones que deben ser verdaderas antes de que el use case se ejecute, un flujo principal que describe el camino feliz, flujos alternativos que describen cada divergencia significativa y postcondiciones que describen lo que es verdadero después de que el use case se completa. El formato te obliga a ser explícito sobre el comportamiento del sistema en modos de falla, que es la parte de una funcionalidad que las user stories sistemáticamente subestiman.

El planteamiento de Cockburn ha envejecido bien. Argumentaba que un use case debería "caber en el reverso de una postal" en su nivel breve y crecer solo cuando el detalle lo demande, lo cual está más cerca en espíritu de las user stories de lo que asume la versión caricaturizada de los use cases. También argumentó que el valor de un use case eran los flujos alternativos, no el flujo principal. El flujo principal describe lo que ya sabes. Los flujos alternativos describen lo que el equipo todavía no ha pensado a fondo, y el acto de escribirlos es el trabajo que el formato hace por ti.

Los use cases son más pesados de escribir que las stories. Un use case razonable le toma a un product manager una o dos horas para una funcionalidad de complejidad moderada, contra diez minutos para la story equivalente. Ese costo es lo que hace que los use cases no sean adecuados como artefacto por defecto para cada ítem del backlog. También es lo que los hace indispensables cuando el costo de un flujo alternativo perdido es mayor que el costo de escribirlo.

Los equipos que perdieron el hábito del use case durante la transición ágil lo están reaprendiendo bajo otros nombres. Las especificaciones de behavior-driven development, los RFC técnicos, los documentos de diseño con diagramas de secuencia y el moderno documento de requerimientos de producto han reabsorbido todos pedazos del formato de use case. La forma es la misma: título, actores, precondiciones, flujo, alternativos, postcondiciones. Lo que cambió fue el nombre y la audiencia.

El formato de user story en profundidad

La plantilla Connextra son tres líneas:

Como [rol] Quiero [acción o funcionalidad] Para [resultado o valor]

Cada línea está haciendo trabajo real. El rol ancla la story en un usuario específico, no en "el usuario" en abstracto. La acción describe lo que el usuario quiere hacer, en su lenguaje, no en el tuyo. El resultado describe el valor que está obteniendo de la acción, que es lo que el equipo va a usar para decidir si la implementación realmente entrega la story o si técnicamente se entregó la funcionalidad sin entregar el valor.

Aquí hay un ejemplo trabajado para una app de banca móvil:

Como titular de cuenta corriente Quiero recibir una notificación cuando se procese un depósito Para verificar rápidamente que los fondos están disponibles antes de hacer una compra

El rol es específico (titular de cuenta corriente, no "usuario"), la acción es observable (recibir una notificación cuando se procesa un depósito) y el resultado es una razón real por la que al usuario le importa (verificar fondos antes de hacer una compra). Una versión más débil de la misma story podría leerse "Como usuario, quiero notificaciones push, para estar informado". Esa story es inconstruible porque no tiene restricciones sobre lo que cuenta como hecho.

Las stories se acompañan de criterios de aceptación, que son condiciones específicas y testeables que tienen que ser verdaderas para que la story se considere entregada. Para el ejemplo de notificación de depósito se ven así:

• La notificación se envía dentro de los 30 segundos posteriores a que el depósito se marque como acreditado en el sistema bancario central

• La notificación incluye el monto, la cuenta de origen u originador, y el nuevo saldo después del depósito

• La notificación respeta las preferencias de notificación del usuario, incluyendo horas de silencio

• La notificación funciona en modo offline, encolada para entrega al reconectarse

• La notificación se registra en el feed de actividad dentro de la app aun cuando la entrega push falle

• La notificación se suprime para depósitos por debajo de un umbral configurable por el usuario

Los criterios de aceptación son lo que convierte una story de una sola frase en un contrato contra el cual el equipo de ingeniería puede construir. No son la implementación, son el comportamiento observable. Una buena regla es que deberías poder entregarle los criterios a un ingeniero de QA que nunca haya visto la funcionalidad y que pueda escribir un plan de pruebas a partir de la lista sola.

Los principios INVEST, atribuidos a Bill Wake, son la heurística canónica para saber si una story está lista para entrar a un sprint. INVEST significa Independent, Negotiable, Valuable, Estimable, Small, Testable. Una story debería ser independiente de otras stories, para que pueda ser secuenciada con libertad. Negociable, para que la conversación pueda dar forma a la implementación. Valiosa, para que el usuario obtenga algo de ella. Estimable, para que el equipo pueda dimensionarla. Pequeña, para que quepa en un sprint. Testeable, para que el equipo pueda demostrar que se entregó. Las stories que fallan en dos o más de estos suelen ser epics que necesitan desarmarse o use cases escondidos dentro de la forma de una story.

Algunos patrones que separan a las stories que se entregan de las stories que se quedan en el tablero. Escribe el rol de manera específica (cliente recurrente con al menos una compra previa, no "usuario"). Escribe el resultado en el lenguaje del usuario (para no tener que volver a escribir mi dirección cada vez, no para que mejoremos la experiencia de usuario). Acompaña con criterios de aceptación que el equipo acuerde antes de empezar la estimación. Resiste el impulso de especificar la implementación en la story; la implementación es trabajo de la conversación. Y mantén la tarjeta corta. Si no cabe en una postal, no pertenece a una story.

El formato de use case en profundidad

Un use case es estructurado. Aquí está la forma canónica, con cada sección haciendo un trabajo específico:

Título. Una frase imperativa corta que nombra el objetivo, escrita desde la perspectiva del actor. Procesar Notificación de Depósito, no Sistema de Notificación de Depósito.

Actor primario. La persona o el sistema cuyo objetivo satisface el use case. La mayoría de los use cases tienen un actor primario.

Actores secundarios. Otros sistemas o personas involucrados en el flujo. Para una notificación de depósito, el sistema bancario central y el proveedor de notificaciones push son actores secundarios.

Precondiciones. Lo que debe ser verdadero antes de que el use case pueda ejecutarse. El usuario está autenticado. El usuario tiene los permisos de notificación concedidos. El depósito ha sido procesado. Las precondiciones son el contrato para entrar al flujo.

Flujo principal. La secuencia numerada de pasos que los actores toman para alcanzar el objetivo. Este es el camino feliz. Cada paso es una acción, escrita en tiempo presente, que describe lo que un actor hace o lo que el sistema hace en respuesta.

Flujos alternativos. Ramificaciones numeradas o con letra que parten del flujo principal y describen divergencias significativas. Fallas, casos límite, caminos secundarios. Cada flujo alternativo especifica de qué paso del flujo principal se ramifica, qué dispara la ramificación y qué pasa después.

Postcondiciones. Lo que es verdadero después de que el use case se completa. Los fondos están disponibles, la notificación está registrada, el rastro de auditoría guarda el evento.

Aquí hay un use case trabajado para la notificación de depósito:

Título: Procesar Notificación de Depósito

Actor primario: Titular de cuenta

Actores secundarios: Sistema bancario central, proveedor de notificaciones push, servicio de notificaciones

Precondiciones:

• El titular de cuenta está autenticado en la app de banca móvil o tiene la app instalada con tokens push válidos

• El titular de cuenta tiene permisos de notificación concedidos a nivel del sistema operativo

• Un depósito ha sido iniciado y está pendiente de procesamiento en el sistema bancario central

Flujo principal:

1. El sistema bancario central procesa el depósito y lo marca como acreditado

2. El sistema bancario central emite un evento depósito-completado al servicio de notificaciones

3. El servicio de notificaciones recibe el evento y consulta las preferencias de notificación del usuario

4. El servicio de notificaciones formatea un mensaje legible para el usuario que incluye el monto, la fuente y el saldo actualizado

5. El servicio de notificaciones entrega el mensaje al proveedor de notificaciones push

6. El proveedor de notificaciones push entrega el mensaje al dispositivo del usuario

7. El usuario recibe la notificación en la pantalla de bloqueo o en la bandeja de notificaciones

8. La notificación se registra en el feed de actividad dentro de la app para referencia posterior

Flujos alternativos:

A1. El usuario tiene las notificaciones desactivadas en las preferencias de la app.

• Ramifica desde el paso 3.

• El servicio de notificaciones suprime la notificación push pero igual escribe el evento en el feed de actividad dentro de la app.

• Postcondición para A1: el usuario puede ver el depósito en el feed de actividad la próxima vez que abra la app.

A2. El dispositivo del usuario está offline al momento de la entrega.

• Ramifica desde el paso 6.

• El proveedor de notificaciones push encola el mensaje para reintento, respetando el TTL configurado.

• Si el dispositivo se reconecta dentro del TTL, la notificación se entrega. Si no, se descarta silenciosamente cuando expira el TTL.

A3. El depósito falla al procesarse.

• Ramifica desde el paso 1.

• El sistema bancario central emite en su lugar un evento depósito-fallido.

• El servicio de notificaciones usa una plantilla de mensaje diferente que explica la falla y los próximos pasos.

• Postcondición para A3: el usuario está informado de la falla y el feed de actividad refleja el estado fallido.

A4. El usuario está dentro de una ventana configurada de horas de silencio.

• Ramifica desde el paso 5.

• El servicio de notificaciones retiene el mensaje hasta que termina la ventana de horas de silencio, y luego lo entrega como notificación de baja prioridad.

A5. El monto del depósito está por debajo del umbral de notificación configurado por el usuario.

• Ramifica desde el paso 3.

• El servicio de notificaciones suprime la notificación push pero igual escribe el evento en el feed de actividad dentro de la app.

Postcondiciones:

• El usuario ha sido informado del estado del depósito a través de al menos uno entre notificación push, feed de actividad dentro de la app o entrega programada

• El evento queda registrado en el rastro de auditoría para reportes de compliance

• Las preferencias de notificación del usuario y la lógica del umbral de depósito han sido respetadas

Mira lo que el formato de use case forzó a salir a la luz. Horas de silencio. Depósitos por debajo del umbral. Ventanas de reintento offline. Depósitos fallidos con su propia plantilla. Nada de eso habría salido de "Como titular de cuenta, quiero una notificación, para saber que mi dinero llegó". La story es verdadera, útil y entregable, pero no es suficiente por sí sola cuando el costo de equivocarse en cualquiera de esos flujos alternativos es una llamada del regulador o un evento de confianza con el cliente.

Ejemplo lado a lado para la misma funcionalidad

La misma funcionalidad, expresada de las dos formas, hace la diferencia concreta. Aquí hay una funcionalidad de una app de pagos: notificar a un cliente cuando una transferencia P2P que envió ha sido recibida por el destinatario.

Versión user story.

Como cliente que ha enviado una transferencia P2P, quiero ser notificado cuando el destinatario reciba los fondos, para saber que la transferencia se completó exitosamente.

Criterios de aceptación:

• La notificación se dispara dentro de los 60 segundos posteriores a que la cuenta del destinatario muestre el crédito

• La notificación incluye el nombre del destinatario, el monto y el ID de transferencia

• La notificación respeta las preferencias de notificación del usuario y las horas de silencio

• La notificación se registra en el feed de actividad

• Las transferencias fallidas disparan una plantilla de notificación diferente

Versión use case.

Título: Notificar al Remitente de la Recepción de la Transferencia P2P Actor primario: Cliente remitente Actores secundarios: Destinatario, servicio de procesamiento de pagos, servicio de notificaciones, servicio de detección de fraude

Precondiciones:

• El cliente remitente ha iniciado una transferencia P2P que ha pasado la validación inicial

• El cliente remitente tiene permisos de notificación concedidos

• El destinatario es un usuario registrado de la plataforma o tiene una cuenta bancaria externa vinculada

Flujo principal:

1. El servicio de procesamiento de pagos confirma que la transferencia ha sido liquidada en la cuenta del destinatario

2. El servicio de detección de fraude ha aprobado la transferencia (no quedan retenciones pendientes)

3. El servicio de notificaciones recibe el evento de liquidación

4. El servicio de notificaciones formatea un mensaje que incluye el nombre del destinatario, el monto y el ID de transferencia

5. El servicio de notificaciones entrega el mensaje al dispositivo del remitente

6. El remitente recibe la notificación

7. El estado de la transferencia en el feed de actividad se actualiza a "recibido"

Flujos alternativos: A1. El servicio de detección de fraude pone una retención sobre la transferencia.

• Ramifica desde el paso 2. No se envía notificación. El feed de actividad muestra la transferencia como "en revisión" y el remitente es notificado a través de un flujo distinto.

A2. El destinatario no está bancarizado o la cuenta externa rechaza el crédito.

• Ramifica desde el paso 1. La transferencia se revierte. La plantilla de notificación informa al remitente de la reversión y de cualquier acción que necesite tomar.

A3. El destinatario tarda más de 30 minutos en registrarse o reclamar la transferencia.

• Ramifica desde el paso 1. Se envía un recordatorio al destinatario a los 30 minutos y a las 24 horas, y al remitente se le notifica al cumplirse las 24 horas.

A4. El remitente ha silenciado las notificaciones de este destinatario específico.

• Ramifica desde el paso 4. La notificación push se suprime pero el feed de actividad igual se actualiza.

Postcondiciones:

• El remitente conoce el estado de su transferencia a través de uno de: notificación push, actualización del feed de actividad o flujo de seguimiento

• El estado de la transferencia en el log de auditoría refleja el resultado final

• Cualquier proceso de fraude, reversión o escheatment se ha disparado si corresponde

Ambos artefactos describen la misma funcionalidad. La story es suficiente para que un equipo co-localizado en un ciclo apretado empiece a construir. El use case es suficiente para un equipo distribuido, un contexto regulado o una funcionalidad que toca suficientes sistemas adyacentes como para que los flujos alternativos se descubrirían de otra forma en producción. La mayoría de los equipos con los que trabajo terminan escribiendo primero la story para alinearse en el valor para el usuario, y luego escribiendo el use case durante el refinamiento para sacar a la luz los flujos que la story se perdió.

Cuándo usar una user story

Las user stories funcionan bien cuando la conversación es barata y el costo de perderse un detalle es bajo. Específicamente:

Estás operando en un ciclo ágil apretado con conversaciones frecuentes presenciales o sincrónicas. El equipo está co-localizado o cerca de eso, con un product manager fuerte que puede responder preguntas dentro de la hora de trabajo. La funcionalidad es lo suficientemente pequeña como para que el equipo pueda mantener el alcance entero en la cabeza al mismo tiempo. Todavía estás validando si la funcionalidad vale la pena construirse, y escribir un use case completo para algo que podrías eliminar la próxima semana es trabajo perdido. El riesgo de equivocarse en un flujo alternativo es acotado: un caso límite perdido se vuelve un ticket de seguimiento rápido, no un evento regulatorio.

Las user stories son el formato dominante en los equipos de producto modernos porque la mayoría de las funcionalidades modernas encajan en esas restricciones. Una app de consumo lanzando una nueva opción de ordenamiento, una herramienta SaaS sumando un atajo de teclado, un sitio web sumando un nuevo filtro a una lista: todos son problemas con forma de story. Escribir un use case para ellos sería ceremonia por la ceremonia.

La otra razón por la que las stories dominan es que coinciden con la cadencia ágil. Un sprint de dos semanas con veinte stories son veinte conversaciones que el equipo puede tener en una semana de grooming. Veinte use cases son un libro chico que nadie lee. Las stories sobreviven porque cambian especificación por conversación, y la conversación es lo que produce buen software.

Una prueba útil: si puedes describir la funcionalidad en una sola frase y un ingeniero senior puede construir un borrador sin hacer más de tres preguntas, la funcionalidad tiene forma de story. Si la primera respuesta del ingeniero es "qué pasa cuando X" y la respuesta a X genera tres preguntas más, la funcionalidad tiene un use case escondido adentro.

Cuándo usar un use case

Los use cases se ganan su lugar cuando la conversación es cara o el costo de equivocarse es alto. La funcionalidad tiene muchos flujos alternativos o casos límite, cinco o más divergencias significativas del camino feliz. Múltiples actores interactúan, incluyendo servicios de terceros, sistemas externos u otros equipos cuyo comportamiento el equipo que construye la funcionalidad no controla. Se requiere documentación regulatoria o de compliance, y el equipo necesita un artefacto que sobreviva una auditoría. El equipo está distribuido en zonas horarias con poco solapamiento, y la conversación se degrada en comentarios asíncronos que necesitan un ancla estructurada.

Los use cases son comunes en industrias reguladas, fintech, salud, seguros, gobierno, y en software empresarial complejo donde las cláusulas contractuales dependen del comportamiento del sistema que el equipo de procurement del comprador va a diseccionar. También son comunes en cualquier funcionalidad que toque identidad, pagos o privacidad de datos, porque los flujos alternativos son donde vive el regulador.

La decisión no es religiosa. Elige un use case cuando escribirlo saca a la luz información que el equipo de otra forma se perdería. Si te encuentras escribiendo un use case en el que los flujos alternativos son trivialmente obvios y el flujo principal tiene cuatro pasos, estás haciendo ceremonia. Si te encuentras escribiendo una story en la que el equipo ha pasado tres sprints descubriendo casos límite que la story no nombró, estás usando el formato equivocado.

Una segunda prueba: si un regulador, un abogado o un oficial de compliance podría leer este artefacto, escribe un use case. Si solo el equipo lo va a leer alguna vez, una story probablemente sea suficiente.

Cuándo usar ambos juntos

El patrón más maduro que he visto es usar ambos, en secuencia. La story dirige la conversación sobre el valor para el usuario durante el descubrimiento de producto. El use case captura el resultado de la conversación durante el refinamiento, sacando a la luz los flujos alternativos que la story no nombró. Ingeniería construye contra el use case. QA prueba contra los criterios de aceptación atados a la story. Los equipos de compliance y auditoría hacen referencia al use case. La story se mantiene lo suficientemente liviana como para reflejar el entendimiento cambiante del usuario; el use case se mantiene lo suficientemente detallado como para sobrevivir una auditoría.

El emparejamiento es especialmente común en:

Fintech y salud, donde la documentación de compliance es innegociable y los flujos alternativos son donde se concentra el costo de equivocarse.

SaaS empresarial con ciclos de venta largos, donde los compradores piden especificaciones antes de firmar y el equipo de procurement trata los use cases como parte del contrato.

Apps móviles y web con casos límite específicos de plataforma, divergencia entre iOS y Android, comportamiento específico del navegador, manejo offline, peculiaridades de notificaciones push. El use case es donde esas divergencias se nombran.

Cualquier funcionalidad donde el equipo ya ha sido mordido antes por perderse un flujo alternativo. Una vez que un equipo ha hecho un post-mortem sobre un flujo perdido, tiende a adoptar el patrón de emparejamiento para funcionalidades similares en adelante.

El costo del emparejamiento es real. Escribir ambos toma más tiempo que escribir uno. El beneficio es que los artefactos hacen trabajos distintos: la story alinea al equipo en el valor, el use case alinea al equipo en el comportamiento, y los dos juntos producen funcionalidades que se entregan limpias la primera vez.

14 patrones y tropiezos al escribir stories o use cases

Estos son los patrones que veo repetidamente en equipos de producto, los que separan a los equipos que entregan de los equipos que discuten sobre el formato.

1. Stories que en realidad no están centradas en el usuario. "Como desarrollador, quiero refactorizar el módulo de auth" es un ticket de deuda técnica, no una user story. Trátalo distinto y ponlo en un backlog de ingeniería separado. Mezclarlos diluye a ambos.

2. Stories sin criterios de aceptación. Sin criterios testeables, "hecho" se convierte en lo que sea que el ingeniero pensó que la story significaba. Acompaña cada story con tres a siete criterios que el equipo acuerde antes de la estimación.

3. Use cases que se leen como stories. Si tu use case es un párrafo y tres pasos, es una story con ropa formal. Usa el formato de story y deja de generar ceremonia.

4. Stories que deberían haber sido use cases. Si el equipo sigue descubriendo casos límite en la implementación que nadie nombró en grooming, el formato story es demasiado delgado. Promueve la próxima funcionalidad similar a use case.

5. El rol escrito de manera genérica. "Como usuario" no te dice nada. "Como cliente recurrente con al menos una compra previa" te dice quién y restringe el diseño.

6. El resultado escrito para la empresa, no para el usuario. "Para que mejoremos el engagement" es la razón de un product manager. "Para no tener que volver a escribir mi dirección cada vez" es la del usuario. Escribe la razón del usuario.

7. Implementación especificada dentro de la story. "Como usuario, quiero un botón en la esquina superior derecha que abra un modal con tres campos" no le deja nada a la conversación. Describe el objetivo, no el diseño.

8. Use cases sin flujos alternativos. El flujo principal es la parte que ya conoces. Los flujos alternativos son donde el formato gana su peso. Un use case sin flujos alternativos es un diagrama de secuencia disfrazado.

9. Precondiciones que esconden los supuestos reales. "El usuario está autenticado" no es suficiente. "El usuario está autenticado Y tiene KYC completado Y tiene al menos una fuente de fondeo vinculada" es lo que el sistema realmente requiere. Escribe el conjunto completo.

10. Criterios de aceptación escritos por una sola persona. Los criterios escritos solo por el PM tienden a capturar el modelo mental del PM. Haz que el ingeniero y el lead de QA los revisen antes del inicio del sprint, y mira con qué frecuencia detectan condiciones faltantes.

11. Tratar stories vs use cases como un debate religioso. Elige el formato que coincida con la complejidad de la funcionalidad y la madurez del equipo. Ambos formatos son herramientas. Las herramientas no son identidades.

12. Saltarse la fuente de la story o use case. Las stories y use cases más fuertes se escriben a partir de comportamiento de usuario observado, no de especulación. Si no puedes señalar los datos, el ticket de soporte o la grabación de sesión que motivaron la story, estás adivinando.

13. Olvidar actualizar el artefacto cuando la funcionalidad cambia. Una story escrita hace seis meses e iterada tres veces en producción no es la story que se entregó. Actualiza el artefacto o mátalo; no dejes que persista como documentación que miente.

14. Escribir el use case después de que la funcionalidad se entrega. El use case es más valioso antes de la implementación, cuando su estructura te obliga a pensar a fondo los flujos alternativos. Escribirlo después como documentación para compliance está bien, pero perdiste el valor de diseño del formato.

Los equipos que manejan bien estos patrones comparten un hábito: tratan al artefacto como un medio para un fin, no como un fin. La story es una forma de alinearse en el valor. El use case es una forma de sacar a la luz flujos. Los criterios son una forma de definir hecho. Ninguno de ellos es un producto de trabajo en sí mismo; la funcionalidad entregada lo es.

Guía específica por industria

Distintas industrias empujan distintos formatos por razones que normalmente están ancladas en regulación, complejidad o distribución.

Fintech y pagos. Los use cases son obligatorios para cualquier flujo que toque movimiento de dinero, KYC o screening de sanciones. Los reguladores leen los use cases durante las auditorías, y los flujos alternativos son donde vive compliance. Las user stories son apropiadas para superficies no reguladas: pantallas de configuración, páginas de marketing, herramientas internas de admin. El patrón de emparejamiento domina: story para valor de usuario, use case para el detalle del flujo. Aterrizar ambos en comportamiento real de usuarios es directo cuando estás corriendo session replay sobre la app autenticada, porque Tara AI dentro de UXCam puede mostrarte los momentos específicos en los que los clientes batallan con el flujo existente antes de que escribas la story para el nuevo. El equipo de experiencia de cliente de Recora usó exactamente este patrón para identificar un gesto de presionar-y-mantener que los clientes no podían descubrir, y luego escribió el rediseño como un emparejamiento story-más-use-case que redujo los tickets de soporte en un 142% (ver el caso de estudio de Recora).

Salud y telesalud. El cumplimiento de HIPAA exige documentación de cualquier flujo que toque información de salud protegida, lo que significa use cases para superficies clínicas, flujos de prescripción y cualquier funcionalidad que maneje identificadores de pacientes. Las stories funcionan para el sitio de marketing, la página pública de agendamiento y otras superficies sin PHI. El costo de un flujo alternativo perdido en salud es daño al paciente, lo que sube la barra de rigor del use case en comparación con apps de consumo.

SaaS B2B. El formato story se adapta a los ciclos rápidos de iteración que corren los equipos de SaaS B2B. Los use cases entran en juego para funcionalidades de integración (donde las APIs de terceros suman flujos alternativos), para funcionalidades de tier empresarial que se entregan bajo contrato y para flujos relevantes para seguridad como SSO y logging de auditoría. El patrón de emparejamiento es común para funcionalidades de tier pago, donde procurement pide especificaciones y el use case se vuelve parte de la venta.

E-commerce y retail. Las stories dominan porque el ciclo es rápido y la mayoría de las funcionalidades tienen forma de story. Los use cases se ganan su lugar en el flujo de checkout, donde los flujos alternativos alrededor de fallas de pago, retenciones por fraude y opciones de envío se multiplican rápido. La optimización de signup de Costa Coffee es un ejemplo útil: el equipo corrió la versión story para el rediseño, después identificó flujos alternativos específicos a partir del session replay (usuarios cayendo en la entrada de OTP, usuarios abandonando cuando las reglas de contraseña aparecían tarde), y el trabajo que levantó los registros en un 15% reflejó ambos formatos.

Gaming y consumo. Las stories funcionan bien para la mayor parte del trabajo de funcionalidad porque el ciclo es rápido, el equipo está co-localizado y el costo de un caso límite perdido es acotado. Los use cases entran para flujos de monetización (compras dentro de la app, suscripciones) y para cualquier funcionalidad que toque estado de cuenta entre dispositivos. Inspire Fitness es un buen ejemplo de cómo el trabajo dirigido por stories puede producir grandes resultados cuando se aterriza en comportamiento real de usuarios: su rediseño de onboarding, escrito como una serie de stories ancladas en fricción observada, levantó el tiempo en app un 460%.

Viajes, hospitalidad y reservas. Los use cases son esenciales para cualquier flujo de reserva porque los flujos alternativos se multiplican rápido: políticas de cancelación, disponibilidad parcial, reservas multi-tramo, divisiones de pago, conversiones de moneda, reservas grupales. Las stories funcionan para todo lo que esté fuera del flujo de reserva en sí. El patrón de emparejamiento es la norma.

La lección general entre industrias es que el formato sigue al costo de equivocarse. Donde un flujo alternativo perdido se vuelve un evento regulatorio, un evento de confianza con el cliente o un incumplimiento contractual, los use cases se ganan su peso. Donde el costo es un ticket de seguimiento rápido y un usuario un poco molesto, las stories son suficientes.

Plantillas listas para copiar

Estas son las plantillas canónicas en markdown plano. Pégalas en la herramienta que prefieras (descripción de Jira, ticket de Linear, doc de Notion, página de Confluence) y adapta los marcadores de posición.

Plantilla de user story:

Título: [frase imperativa corta]

Como [rol específico con atributos relevantes] Quiero [acción o funcionalidad observable] Para [resultado que el usuario realmente valora]

Criterios de aceptación:

• [Condición específica y testeable #1]

• [Condición específica y testeable #2]

• [Condición específica y testeable #3]

• [Condición específica y testeable #4]

• [Condición específica y testeable #5]

Notas / preguntas abiertas:

• [Cualquier cosa que todavía se esté clarificando antes del inicio del sprint]

Fuente / evidencia:

• [Link al session replay, ticket de soporte, gráfico de analytics o hallazgo de research que motivó esta story]

Plantilla de use case:

Título: [frase imperativa que nombre el objetivo]

Actor primario: [el actor cuyo objetivo esto satisface]

Actores secundarios: [otras personas, sistemas o servicios involucrados]

Precondiciones:

• [Lo que debe ser verdadero antes de que este use case pueda ejecutarse]

• [Específicamente el estado del usuario y del sistema]

Flujo principal:

1. [Paso uno, acción del actor o del sistema]

2. [Paso dos]

3. [Paso tres]

4. [Continúa con los pasos numerados hasta el objetivo]

Flujos alternativos:

A1. [Condición que dispara el primer flujo alternativo]

• Ramifica desde el paso [N].

• [Qué pasa]

• Postcondición: [Qué es verdadero después de este flujo alternativo]

A2. [Disparador del segundo flujo alternativo]

• Ramifica desde el paso [N].

• [Qué pasa]

• Postcondición: [Qué es verdadero después de este flujo alternativo]

A3. [Disparador del tercer flujo alternativo]

• [Continúa para cada divergencia significativa]

Postcondiciones:

• [Qué es verdadero después de que se completa el use case]

• [Incluyendo el estado de auditoría, logging o compliance]

Plantilla de criterios de aceptación (variante Given-When-Then):

Given [el estado inicial del usuario y del sistema] When [el usuario toma una acción específica] Then [el resultado observable que debería ocurrir]

Usa el formato Given-When-Then cuando los criterios necesiten ser testeables por automatización, particularmente para flujos de behavior-driven development. Usa el formato más simple de lista con bullets cuando los criterios se vayan a chequear manualmente durante QA. Ambos funcionan; la elección depende de tu postura de testing.

Plantilla de emparejamiento story-más-use-case (para el patrón combinado):

Story (parte superior del ticket): Como [rol], quiero [acción], para [resultado].

Criterios de aceptación: 3-7 condiciones testeables.

Use case vinculado (página separada, enlazada desde el ticket): use case estructurado completo como arriba.

Fuente: link al session replay, tendencia de tickets o hallazgo de analytics que motivó el trabajo.

La plantilla de emparejamiento es la que recomiendo para cualquier funcionalidad donde un flujo alternativo perdido tiene consecuencias mayores que un usuario molesto. La story mantiene al equipo alineado en el valor, el use case mantiene al equipo alineado en el comportamiento, y el link entre ellos los mantiene a ambos honestos.

Dónde el análisis de sesiones con IA informa a ambos

El formato que eliges está aguas abajo de la pregunta de dónde vienen los inputs. Una user story escrita desde la especulación es peor que ninguna user story, porque codifica los sesgos del equipo como trabajo a entregar. Un use case escrito desde el modelo mental de un product manager es igual de frágil. Ambos formatos son tan buenos como el entendimiento de usuario que hay detrás, y la mayoría de los equipos subestiman cuánto de ese entendimiento viene de la observación más que de la intuición.

Aquí es donde el análisis de sesiones con IA cambia la práctica. Tara AI dentro de UXCam lee session replays a escala, agrupa patrones de fricción por impacto en el negocio y saca a la luz los momentos específicos por los que vale la pena escribir stories. En lugar de un product manager adivinando con qué baten los usuarios, la capa de analista le entrega una lista priorizada: este paso de onboarding está produciendo rage taps, este error de checkout está matando la conversión, este patrón de navegación está perdiendo usuarios recurrentes.

Eso cambia el input para escribir stories. El rol en "Como [rol]" se vuelve específico porque los datos te dicen qué segmento está afectado. La acción se vuelve observable porque has visto a los usuarios intentarla. El resultado se vuelve real porque has visto el momento en el que los usuarios se rindieron. Los criterios de aceptación se vuelven testeables porque sabes cómo se ve la falla existente y puedes especificar el arreglo en términos observables.

La misma dinámica aplica a los use cases. Los flujos alternativos que escribes son tan buenos como los modos de falla que has visto. Un use case escrito desde la imaginación se pierde los flujos alternativos que aparecen en producción. Un use case escrito desde datos de sesión observados, los momentos específicos en los que los usuarios pegan con una notificación de hora de silencio, un reintento offline, un depósito por debajo del umbral, una retención por fraude, captura los flujos alternativos que efectivamente ocurren.

Un flujo de trabajo práctico se ve así. Tara AI saca a la luz un cluster de fricción: el 12% de los usuarios en el flujo de notificación de depósito experimentan una supresión por debajo del umbral que no esperaban. El product manager escribe una user story para el arreglo, anclada en los momentos específicos que la IA marcó. Durante el refinamiento, el equipo escribe un use case que nombra el flujo alternativo de manera explícita. Ingeniería construye contra el use case. QA prueba contra los criterios de aceptación. El arreglo se entrega y el cluster de fricción se reduce. Nadie adivinó el input, y el producto de trabajo refleja realidad observada en lugar del modelo mental previo del equipo.

Esta es la línea conductora que atraviesa los resultados más fuertes de los clientes de UXCam. Recora redujo los tickets de soporte en un 142% porque escribió la story del rediseño a partir de un patrón específico de fricción que el session replay sacó a la luz. [Inspire Fitness](https://uxcam.com/case-study/inspire