Una historia de usuario describe funcionalidad deseada desde la perspectiva del cliente (el usuario). Una buena historia de usuario describe esta funcionalidad, quién la necesita, y cómo y porqué se va a utilizar. Los componentes básicos de una Historia de Uusario se pueden resumir en tres elementos:
- Tarjeta: es la descripción escrita de la historia, que sirve como identificación, recordatorio y también ayuda a planificar.
- Conversación: es el núcleo de la historia; es el diálogo que ocurre con los usuarios, notas, grabaciones, prototipos y documentos.
- Confirmación: el criterio de las pruebas de aceptación que el usuario va a utilizar para confirmar que la historia fue terminada.
Estos elementos se conocen como Las 3 C de una Historia de Usuario, por sus iniciales en inglés (Card, Conversation, Confirmation).
Una historia de usuario no es técnica.
El modelo INVEST
Una buena historia de usuario también sigue el modelo de INVEST: Independiente, Negociable, Estimable, Pequeña (Small), y Testeable. Veamos lo que significa.
- Independiente - una historia debería ser independiente de otras (lo más posible). Las dependencias entre las historias hace que sea más dificil planificar, priorizar y estimar. A menudo, se puede reducir las dependencias haciendo una combinación de historias, o partiendo historias de forma diferente.
- Negociable - una historia de usuario es negociable. La "tarjeta" de la historia es tan sólo una descripción corta que no incluye detalles. Los detalles se trabajan durante la etapa de "Conversación". Una tarjeta con demasiados detalles limita la conversación con el cliente.
- Valiosa - cada historia tiene que tener valor para el cliente (para el usuario o para el comprador). Una forma muy buena de generar historias valiosas es hacer que el cliente las escriba. Una vez que el cliente se de cuenta que la historia no es un contrato y es negociable, van a sentirse mucho más cómodos para escribir historias.
- Estimable - los desarrolladores necesitan poder estimar una historia de usuario para permitir que se pueda priorizar y planificar la historia. Los problemas que pueden impedirle a los desarrolladores estimar una historia son: falta de conocimiento del dominio (en cuyo caso se necesita más Negociación / Conversación); o si la historia es muy grande (en cuyo caso se necesita descomponer la historia en historias más pequeñas).
- Pequeña - una buena historia debe ser pequeña en esfuerzo, generalmente representando no más de 2-3 personas/semana de trabajo. Una historia que es más grande va a tener más errores asociados a la estimación y alcance.
- Testeable - una historia necesita poder probarse para que ocurra la etapa de "Confirmación". Recordemos que desarrollamos aquello que no podemos probar. Si no podemos probarlo, nunca vamos a saber si lo terminamos. Un ejemplo de historia no testeable sería: "el software tiene que ser facil de usar".
Conclusión
Las historias de usuario bien escritas son esenciales para el Desarrollo Ágil. Deben ser independientes entre si; se debe poder negociar los detalles entre los usuarios y los desarrolladores; las historias deben tener valor para el c liente; deben ser lo suficientemente claras para que los desarrolladores puedan estimarlas; deben ser pequeñas; y deben poder probarse usando los casos de prueba pre-definidos.
