Descomponer en historias de usuario
Resumen
Este skill toma una funcionalidad o requisito de alto nivel y lo descompone en historias de usuario granulares, cada una con criterios de aceptación, prioridad y estimación relativa. El objetivo es producir unidades de trabajo que un desarrollador pueda implementar de forma independiente en un máximo de 8 horas.
La descomposición sigue el principio INVEST: cada historia debe ser Independiente, Negociable, Valiosa, Estimable, Pequeña y Testeable. Historias que no cumplan estos criterios se dividen hasta que los cumplan.
Proceso
- Entender la funcionalidad completa. Revisar el PRD si existe, o pedir al usuario que describa la feature. Identificar los actores implicados, los flujos principales y los flujos alternativos.
- Identificar los roles de usuario. Listar todos los perfiles que interactúan con la funcionalidad: usuario final, administrador, sistema externo, etc. Cada rol puede generar historias distintas.
- Redactar historias con el formato estándar:
`` Como [rol], quiero [acción concreta], para [beneficio medible]. ``
Evitar historias vagas como "Como usuario, quiero que funcione bien". La acción debe ser específica y el beneficio debe explicar el valor real.
- Añadir criterios de aceptación a cada historia. Mínimo 2 criterios por historia: uno para el camino feliz y otro para un caso límite o error. Formato Given/When/Then preferible.
- Asignar prioridad con MoSCoW:
- Must have: sin esto la feature no tiene sentido.
- Should have: importante pero no bloqueante para un primer lanzamiento.
- Could have: mejora la experiencia pero se puede posponer.
- Won't have (this time): descartado para esta iteración, documentado para referencia futura.
- Estimar de forma relativa. Usar tallas de camiseta (S, M, L) o puntos de historia. La referencia es que una historia no debe superar 8 horas de trabajo. Si se estima mayor, dividirla.
- Verificar independencia. Repasar que cada historia pueda implementarse y desplegarse sin depender del resto. Si hay dependencias, documentarlas explícitamente y ordenar en consecuencia.
- Presentar al usuario para validación. Revisar la lista completa, ajustar prioridades y estimaciones según feedback.
Criterios de éxito
- Cada historia sigue el formato "Como / quiero / para" con roles, acciones y beneficios concretos.
- Todas las historias tienen al menos 2 criterios de aceptación.
- Ninguna historia supera las 8 horas estimadas de trabajo.
- Las prioridades MoSCoW están asignadas y son coherentes con el objetivo de la feature.
- El usuario ha validado la descomposición y las prioridades.
Que NO hacer
- No escribir historias demasiado grandes. Si una historia no se puede implementar y verificar en un máximo de 8 horas, necesita dividirse en historias más pequeñas.
- No mezclar múltiples acciones en una sola historia. Cada historia debe representar una unidad de valor independiente que se pueda desplegar por separado.
- No omitir los criterios de aceptación. Una historia sin criterios de aceptación no es verificable y genera ambigüedad entre producto y desarrollo.