METODOLOGÍA

User Story

Una descripción breve de una funcionalidad contada desde el punto de vista del usuario, con la forma 'Como [rol], quiero [objetivo], para que [beneficio]', usada para capturar la intención en lugar de una especificación técnica.

Última revisión: 2026-06-02 porKevin Riedl wiki ↗

Una historia de usuario captura una pieza de valor desde la perspectiva de la persona que la quiere, normalmente con el formato “Como [rol], quiero [objetivo], para que [beneficio]”. El formato no es burocracia por sí misma. El “como” te obliga a nombrar quién quiere esto realmente, y el “para que” te obliga a declarar el porqué, que es la parte que los equipos se saltan y entonces construyen lo equivocado. Una historia es un marcador de posición para una conversación, no un contrato.

Las buenas historias suelen cumplir los criterios INVEST: Independent (se puede construir por sí sola), Negotiable (los detalles quedan abiertos hasta que los discutes), Valuable (entrega algo que le importa a un usuario o comprador), Estimable (el equipo puede dimensionarla), Small (cabe dentro de una iteración) y Testable (puedes saber cuándo está hecha). En los dos últimos es donde se desmoronan la mayoría de las historias: demasiado grandes para terminar, o escritas de forma tan vaga que nadie sabe decir qué significa “hecho”.

Los criterios de aceptación son cómo una historia se vuelve comprobable. Son las condiciones concretas que deben cumplirse para que la historia se acepte, escritas antes de que empiece el trabajo. “Como usuario quiero restablecer mi contraseña” es una intención. Los criterios de aceptación (un enlace de restablecimiento expira tras una hora, un token inválido muestra un error claro, un restablecimiento con éxito inicia la sesión del usuario) son contra lo que el equipo realmente construye y prueba.

El antipatrón común es la historia que es una tarea disfrazada. “Como desarrollador quiero añadir un índice a la tabla de pedidos” lleva puesto el disfraz de historia de usuario, pero no hay usuario ni beneficio, solo una tarea de ingeniería con sombrero. Está bien rastrearla, pero no es una historia de usuario, y disfrazar tareas técnicas de historias borra calladamente la perspectiva del usuario que el formato existe para proteger.

// FAQ

Preguntas frecuentes

Preguntas frecuentes

Una descripción breve de una funcionalidad desde el punto de vista del usuario, normalmente ‘Como [rol], quiero [objetivo], para que [beneficio]’. Captura quién quiere algo y por qué, y actúa como un marcador de posición para una conversación en lugar de una especificación técnica completa.
Una lista de verificación para una buena historia: Independent, Negotiable, Valuable, Estimable, Small y Testable. La mayoría de las historias fallan en Small (demasiado grandes para terminar en una iteración) o Testable (demasiado vagas para definir hecho). Los criterios son una forma rápida de detectar historias que darán problemas antes de que el equipo se comprometa.
Cuando es una tarea técnica disfrazada. ‘Como desarrollador quiero añadir un índice de base de datos’ no tiene usuario real ni beneficio, solo una tarea de ingeniería con disfraz. Rastrear ese trabajo está bien, pero llamarlo historia de usuario borra la perspectiva del usuario que el formato existe para proteger, lo que anula su propósito.