Cómo Crear Historias de Usuario en Proyectos Técnicos
1. Principios generales
Las Historias de Usuario deben:
Ser breves, claras y orientadas al valor.
Enfocarse en qué se necesita y para qué.
No incluir detalles técnicos en la frase principal (eso va en la descripción extendida).
Mantener siempre una estructura repetible para facilitar su uso en Odoo Projects.
La estructura HU formal debe ir en la descripción, nunca en el título.
2. Estructura del título
El título debe ser:
Imperativo (orden de acción)
Corto
Descriptivo de lo que hay que hacer
Ejemplos:
“Crear endpoint mock de productos”
“Configurar base de datos inicial”
“Implementar autenticación con Odoo API"
3. Estructura de la Historia de Usuario (en la descripción)
Toda HU debe comenzar con la frase formal:
🔹 3.1. Historia de Usuario (HU)
Formato obligatorio:
“Como [rol], quiero [necesidad], para [beneficio].”
Ejemplos:
“Como integrador, quiero leer productos desde Odoo, para validar la comunicación base del proyecto.”
“Como backend developer, quiero procesar datos mock, para probar el flujo interno sin depender de plataformas externas.”
Componentes:
Rol: quién necesita la funcionalidad
Necesidad / acción: qué se requiere
Beneficio: para qué sirve / qué valor aporta
4. Descripción extendida
Después de la HU formal, se incluye un texto corto que amplía:
Alcance
Supuestos
Límites de la tarea
Notas técnicas relevantes (sin sobrecargar)
Ejemplo:
“Esta tarea incluye crear el endpoint /mock/products que devuelva datos en formato JSON y preparar la estructura para futuras simulaciones.”
5. Criterios de Aceptación
Los criterios de aceptación (CA) validan cuándo la tarea está realmente cumplida.
Reglas:
Ser objetivos, medibles y binarios (cumple / no cumple)
Evitar frases ambiguas (“funciona bien”, “se ve correcto”)
Representan la definición de terminado (DoD) de esa HU
Ejemplo:
El endpoint /mock/products responde 200.
Devuelve un JSON con al menos 3 productos.
Los errores se registran en la tabla logs.
El código se encuentra en el repositorio principal.
6. Entregables
El entregable es el resultado tangible de la HU.
Debe ser un objeto verificable:
Un endpoint funcionando
Un script subido al repositorio
Un documento
Un workflow en n8n
Una tabla creada en la base de datos
Un acceso configurado
Un registro creado en Odoo
Ejemplo:
“Endpoint /mock/products disponible en FastAPI con ejemplo JSON documentado.”
7. Estimación de horas (mínima y máxima)
Toda HU debe incluir una estimación de rango:
Estimación mínima: si todo sale bien
Estimación máxima: contemplando imprevistos razonables
Ejemplo:
Estimación: 2 h – 4 h
Recomendaciones:
No usar rangos demasiado amplios (ej. 2–10 h).
Para tareas grandes, dividir en HUs más pequeñas.
El rango debe ser realista para evitar retrasos acumulados.
8. Campos adicionales sugeridos
No son obligatorios, pero recomendados:
Rol Responsable: quién ejecuta la HU
R / A (RACI): quién responde y quién aprueba
Etiquetas: facilita filtrado en Odoo Project
Relación con épica o fase: mantiene la trazabilidad
9. Ejemplo completo de HU
Título:
Crear endpoint mock de productos
Descripción (HU formal + detalle):
Historia de Usuario:
“Como backend developer, quiero crear un endpoint mock de productos, para simular una tienda externa sin depender de WooCommerce.”
Descripción extendida:
El endpoint debe devolver un listado de productos ficticios en formato JSON. Servirá para probar el pipeline Alinea → Odoo sin plataformas externas.
Criterios de Aceptación:
El endpoint /mock/products responde HTTP 200.
Devuelve un JSON válido con campos: name, sku, price.
El endpoint está documentado con un ejemplo.
Se registran los accesos en logs.
Entregable:
Endpoint funcional + archivo de documentación incluido en el repositorio.
Estimación:
2 h – 4 h