Historias de Usuario: Conectar Necesidades con Desarrollo
Las historias de usuario son la forma estándar en que los PMs comunican requerimientos al equipo de desarrollo. Una buena historia explica quién necesita qué y por qué, sin dictar cómo implementarlo.
Formato clásico de una historia de usuario
- Como [tipo de usuario], quiero [acción/funcionalidad], para que [beneficio/objetivo]
- Ejemplo: 'Como freelancer, quiero exportar mis facturas en PDF, para que pueda enviarlas por email a mis clientes'
- El 'para que' es la parte más importante — explica el por qué y permite al equipo proponer soluciones alternativas
- Si no puedes completar el 'para que', probablemente la feature no tiene un problema real detrás
- Escribe historias desde la perspectiva del usuario, no desde la perspectiva del sistema
Criterios de aceptación
- Son las condiciones que deben cumplirse para que la historia se considere 'terminada'
- Formato: 'DADO [contexto], CUANDO [acción], ENTONCES [resultado esperado]'
- Ejemplo: 'DADO que tengo una factura creada, CUANDO hago clic en Exportar PDF, ENTONCES se descarga un PDF con el logo, datos del cliente y líneas de la factura'
- Incluye 3-7 criterios por historia — pocos es ambiguo, demasiados es over-engineering
- Incluye casos edge: ¿qué pasa si no hay datos? ¿Si el usuario no tiene permiso? ¿Si la conexión falla?
Consejos para escribir buenas historias
- INVEST: Independent (independiente), Negotiable (negociable), Valuable (valiosa), Estimable, Small (pequeña), Testable
- Una historia debe poder completarse en un sprint (1-2 semanas) — si es más grande, divídela
- Incluye mockups o wireframes como referencia visual — una imagen vale más que 100 palabras de especificación
- No dictes la implementación: 'exportar en PDF' es correcto, 'usar la librería pdfkit con Express' no — eso lo decide el equipo técnico
- Revisa las historias con el equipo antes del sprint planning — resolver dudas temprano ahorra retrabajo
Consejo: La historia de usuario perfecta cabe en un post-it. Si necesitas una página entera para explicar una feature, probablemente es demasiado grande y necesita dividirse.