2. Agilidad en Papel: Historias de Usuario

Escribiendo Historias de Usuario

Atrás quedaron los documentos de 500 páginas de Cascada. En metodologías ágiles como Scrum, los desarrolladores usan Historias de Usuario (User Stories). Estas capturan una funcionalidad desde la perspectiva de quien la usa.

Ejemplo: "Como Usuario Registrado, quiero restablecer mi contraseña por email, para poder acceder a mi cuenta si la olvido."

El modelo INVEST

Una buena historia de usuario debe cumplir las siglas INVEST:

• Independent (Independiente de otras historias)
• Negotiable (Negociable: Es una invitación a charlar, no un contrato rígido)
• Valuable (Aporta valor real al cliente o negocio)
• Estimable (El equipo puede aproximar su esfuerzo)
• Small (Suficientemente pequeña para terminarla en 1 Sprint/Iteración)
• Testable (Testeable: Debe haber forma de comprobar que funciona)

Criterios de Aceptación

Son la lista de condiciones que debe cumplir el software para que la historia se considere "Terminada". Sirven para alinear al QA, al cliente y al Developer.

Ejemplo para recuperar contraseña:
1. "El sistema envía un email formateado con un link seguro".
2. "El link expirará a los 15 minutos".
3. "Al intentar usar un link expirado da error 400".

Priorización y el Product Backlog

El contenedor de todas las historias de usuario de un producto se llama Product Backlog. Está ordenado desde arriba (lo más importante) abajo.

Una técnica estelar para ordenar esto es MoSCoW:

• Must Have: Crítico. Sin esto, el sistema no tiene sentido.
• Should Have: Importante pero no de vida o muerte.
• Could Have: Algo "bonito de tener" si sobra tiempo o plata.
• Won't Have: En esta versión inicial (MVP), definitivamente no lo haremos.

Ponte a prueba