Uso de "Historias de Usuario" como Subtareas en los Proyectos - Marco metodológico
1. Introducción
Dentro de la estructura metodológica de Crumges:
Las Fases organizan el proyecto a nivel macro
Las Épicas organizan grandes bloques dentro de una fase
Las Historias de Usuario organizan tareas concretas dentro de cada épica
Las Etapas indican el estado del flujo de trabajo
Las Historias de Usuario son la unidad mínima de trabajo gestionable, permiten ejecutar una Épica de manera ordenada y aseguran que cada avance tiene un propósito, un alcance y un entregable medible.
2. ¿Qué es una Historia de Usuario (HU)?
Cada HU:
Representa una necesidad puntual
Debe generar un entregable claro
Es asignable a una persona
Puede estimarse en tiempo
Puede completarse dentro de la misma Fase
Debe cumplir criterios de aceptación medibles
La HU NO describe “cómo hacerlo”, sino qué se debe lograr y por qué.
3. Estructura estándar de una Historia de Usuario
Toda Historia de Usuario debe redactarse siguiendo este formato:
3.1. Título claro y concreto
Debe describir el resultado esperado, no la acción.
Incorrecto: “Revisar la API”
Correcto: “Definir endpoints base de la API Interna”
3.2. Redacción en formato estándar “Como / Quiero / Para”
Este formato asegura la comprensión del contexto:
Como (rol o responsable)
Quiero (resultado esperado)
Para (propósito o beneficio)
Ejemplo:
Como responsable técnico del proyecto, quiero definir el modelo mínimo de entidades internas, para poder soportar la sincronización inicial del sistema.
3.3. Alcance
Define qué incluye la HU y qué queda fuera.
3.4. Entregable
Debe ser un resultado concreto, verificable y demostrable.
Ejemplos de entregables válidos:
documento
decisión técnica
endpoint funcional
registro en la BD
prototipo funcional
lógica implementada
mock
checklist
script probado
3.5. Criterios de aceptación
Son reglas objetivas que indican cuándo la Historia está realmente finalizada.
Ejemplos:
El endpoint responde con código 200
El documento está redactado con estructura aprobada
El mock simula correctamente el comportamiento esperado
El flujo n8n → FastAPI genera el log correspondiente
Los criterios de aceptación evitan subjetividad.
3.6. Estimación en horas
Las HU deben ser:
cortas
manejables
estimables
Normalmente entre:
1 hora y 4 horas, o
máximo 6 horas si la tarea es más compleja.
Si una HU supera 8 horas → debe dividirse.
3.7. Relación con la Épica
Cada HU debe estar asociada a una sola Épica.
Si encaja en más de una, la épica está mal definida.
4. ¿Qué NO es una Historia de Usuario?
Para evitar errores comunes:
❌ No es una épica reducida
Si el resultado implica varios objetivos → es una épica, no una HU.
❌ No es una actividad genérica
Incorrecto: “Trabajar en logs”
❌ No es un recordatorio o una nota
Incorrecto: “Investigar un poco sobre X”
❌ No es un punto de reunión
Incorrecto: “Reunión del lunes”
(Las reuniones son hitos o tareas administrativas)
❌ No describe “cómo hacerlo”
Las HU describen qué lograr, no cómo implementarlo.
5. Subtareas
Las subtareas existen cuando una Historia de Usuario:
es técnica
debe ejecutarse en pasos definidos
implica acciones secuenciales
requiere desglosar microactividades
Una HU puede no tener subtareas si es simple.
Pero si tiene subtareas, estas deben seguir las reglas:
5.1. Las subtareas NO tienen estructura de HU
No llevan el formato “Como/Quiero/Para”.
Se redactan como microacciones:
Ejemplo:
Crear archivo models.py
Definir entidad ProductSync
Implementar endpoint /mock/products
Probar respuesta mock
5.2. Cada subtarea debe producir un microresultado
Una subtarea no debe ser un acto administrativo vacío.
5.3. Pueden tener estimación individual
Esto permite precisión en el control del tiempo.
5.4. Las subtareas no existen si la HU es suficientemente pequeña
Evita la sobresegmentación innecesaria.
6. Buenas prácticas para escribir HU
✔ 6.1. La HU debe ser independiente
Que no dependa obligatoriamente de otra HU salvo excepciones.
✔ 6.2. Debe tener un resultado claro
Si no se puede medir el resultado → la HU está mal definida.
✔ 6.3. Debe poder completarse dentro de la Fase
Si no, debe pasar a Fase siguiente o dividirse.
✔ 6.4. Debe evitar palabras ambiguas
Nunca: “un poco”, “aproximado”, “más o menos”.
✔ 6.5. Debe tener una persona responsable
Nunca dejar HU sin dueño.
7. Ejemplos aplicados (caso Alinea)
Estos ejemplos están alineados con tu proyecto real.
HU: Definir objetivos generales del proyecto
Como responsable del proyecto
Quiero redactar los objetivos principales del sistema Alinea
Para establecer una base clara para la fase fundacional
Alcance: Documento inicial con propósito, visión y metas técnicas
Entregable: Documento de objetivos
Criterios de aceptación: Documento con 3 secciones aprobadas
Horas estimadas: 1 h
Épica: Documento Fundacional
HU: Crear endpoint mock de productos
Como desarrollador
Quiero implementar un endpoint mock que simule WooCommerce
Para validar la arquitectura sin requerir plataforma externa
Alcance: Endpoint GET y POST
Entregable: Endpoint funcional en FastAPI
Criterios de aceptación: Retorna datos mock y guarda en BD
Horas: 2 h
Épica: Validación Técnica Base
HU: Probar conexión real con API de Odoo
Como integrador técnico
Quiero probar lectura y creación de productos vía API
Para validar la viabilidad del modelo Odoo Online
Entregable: Script o llamada probada
Criterios: Código 200 y creación exitosa del registro
Horas: 3 h
8. Relación entre HU y el flujo del proyecto
Una HU:
inicia en Planificación
avanza según su naturaleza por el flujo de Etapas
termina en Finalizado
Las HU son las piezas que realmente se mueven por las Etapas.
9. Conclusión
Las Historias de Usuario constituyen la unidad mínima de trabajo dentro de la metodología de Crumges.
Su correcta definición permite:
ejecutar épicas de forma ordenada
medir esfuerzo con precisión
producir entregables concretos
evitar ambigüedades
avanzar cada fase de manera sólida