System Design
Historias de usuario
Explica cómo usar historias de usuario para organizar conversaciones y valor sin convertirlas en sustitutos de reglas, modelos, estados o requisitos detallados.
- Última actualización
- Actualizada
- Nivel
- Fundamentos
System Design
Explica cómo usar historias de usuario para organizar conversaciones y valor sin convertirlas en sustitutos de reglas, modelos, estados o requisitos detallados.
Una historia de usuario no es una especificación comprimida ni una tarea con formato “Como… quiero… para…”. Es un recordatorio de una conversación sobre valor, alcance, reglas y evidencia de aceptación.
Las historias ayudan a organizar entrega incremental desde la perspectiva de quien obtiene un resultado.
rol + necesidad + beneficio
→ conversación
→ ejemplos y criterios
→ entrega verificableEl texto breve no contiene todo el conocimiento. La calidad depende de la conversación, las reglas relacionadas y los criterios que confirman el comportamiento.
Los requisitos extensos pueden ser difíciles de priorizar y entregar. Las historias permiten cortar una capacidad en resultados pequeños que el equipo puede discutir, implementar y validar.
Pero una historia mal usada crea problemas:
Como [rol]
quiero [capacidad]
para [beneficio]Ejemplo:
Como encargado de inventario,
quiero registrar una entrada de productos,
para mantener actualizada la disponibilidad de la sucursal.El beneficio permite cuestionar la solución. Quizá importar un archivo o recibir datos del proveedor resuelve mejor la necesidad que un formulario manual.
Título o texto breve que identifica la necesidad.
Discusión sobre alcance, reglas, alternativas, datos, riesgos y decisiones.
Ejemplos y criterios que permiten aceptar el resultado.
Si solo existe la tarjeta, la historia está incompleta.
historia
├─ por qué: objetivo y beneficio
├─ qué: capacidad observable
├─ límites: alcance y reglas
├─ ejemplos: criterios de aceptación
└─ conexiones: requisitos, diseño y pruebasEl rol debe explicar una necesidad diferenciada, no un permiso genérico.
Débil: Como usuario...
Mejor: Como store manager responsable de una sucursal...No necesitas crear una historia distinta por cada persona cuando comparten objetivo y reglas. Tampoco uses “como sistema” salvo que represente un actor o proceso real; normalmente una automatización se expresa mejor como evento o requisito.
Débil: para poder usar la funcionalidad
Mejor: para detectar diferencias antes del cierre de cajaEl beneficio conecta con un resultado y ayuda a priorizar. Si no puede explicarse, la capacidad quizá sea una solución sin problema claro.
Puede cambiar o entregarse con dependencia mínima. No implica aislamiento absoluto.
El texto no congela la solución antes de conversar.
Aporta resultado o aprendizaje identificable.
El equipo entiende suficientemente alcance y riesgo.
Cabe en un horizonte corto sin esconder trabajo crítico.
Existen ejemplos observables.
INVEST es una guía de diagnóstico, no una fórmula. Una historia regulatoria puede no ser negociable; una integración puede necesitar dependencias inevitables.
Un corte vertical atraviesa las capas necesarias para entregar una capacidad.
mal corte
- crear tabla orders
- crear endpoint
- crear pantalla
corte vertical
- registrar un pedido sencillo y verlo en operacionesNo dividas dejando seguridad, integridad o recuperación crítica para “después”.
Épica demasiado amplia:
Como administrador quiero gestionar inventario.Cortes posibles:
Cada historia debe conservar reglas compartidas: cantidades válidas, autorización, trazabilidad y consistencia.
Título: Registrar entrada de inventario
Como encargado de inventario de una sucursal,
quiero registrar unidades recibidas de un producto,
para que el stock vendible refleje la mercancía disponible.
Contexto:
- Solo productos activos de la sucursal.
- La cantidad debe ser positiva.
- Toda entrada requiere motivo y referencia opcional.
Resultado:
- Se crea un movimiento inmutable.
- Se actualiza la existencia.
- Se registra actor y fecha.
Fuera de alcance:
- Crear productos nuevos.
- Gestionar factura de compra.Los criterios cubren duplicados, concurrencia, producto inexistente y repetición de la misma referencia.
Agrupa alcance demasiado grande para entrega directa.
Capacidad más amplia que puede contener varias historias.
Trabajo que habilita valor posterior: migración, infraestructura o contrato.
Experimento con tiempo limitado para responder una pregunta y producir evidencia.
No conviertas cada tarea técnica en historia ficticia de usuario. Explica qué habilita y cómo se considera terminada.
Una historia puede depender de otra, pero un backlog totalmente encadenado indica cortes horizontales o modelo incompleto.
Busca:
La independencia busca flexibilidad de planificación, no negar relaciones reales.
Una historia hereda cualidades del flujo. No copies “debe ser seguro” en todas. Relaciona SLOs, permisos y estándares comunes, y añade criterios específicos cuando cambie el riesgo.
Ejemplo: importar 100 000 filas necesita límites y procesamiento diferente a registrar una unidad manual.
“Cambiar color de botón” puede ser tarea dentro de una historia, salvo que tenga valor independiente probado.
Si mezcla múltiples actores, estados y resultados, divídela por flujo o regla.
Descríbelo como enabler con impacto y criterio técnico, sin inventar usuario.
Mantén una fuente autoritativa y enlázala; no la copies en todas las historias.
Mantén preguntas abiertas y usa spike; no finjas estimabilidad.
Incluye contrato, fallback y evidencia de disponibilidad.
Una mala necesidad no mejora por anteponer “Como usuario”.
“Como Laura” no permite generalizar responsabilidad.
“Quiero un modal” limita alternativas sin necesidad.
“Para gestionar mejor” no permite medir valor.
Ninguna parte produce resultado usable por sí sola.
El equipo descubre reglas durante desarrollo y multiplica retrabajo.
“Crear endpoint” no confirma comportamiento.
Un refinamiento útil responde:
No requiere definir toda implementación antes de comenzar.
Puede ayudar como checklist, pero no debe convertirse en barrera burocrática. Una historia está lista cuando existe comprensión suficiente para asumir el riesgo de desarrollarla, no cuando todos los campos están llenos.
Pueden ser una mala representación para:
Utiliza el artefacto que comunique mejor el trabajo.
Criterios de aceptación convierte la conversación en ejemplos observables que permiten confirmar el resultado.