Una historia de usuario (Scrum) describe funcionalidad que se desea desde la perspectiva del cliente o usuario. Una buena historia de usuario describe:

  • La funcionalidad que se requiere
  • Quién la necesita, y
  • Cómo y porqué se va a utilizar.

Los componentes básicos que no se deben omitir en una historia de usuario las podemos resumir en tres elementos principales:

  1. Tarjeta: es la descripción escrita de la historia, que sirve como identificación, recordatorio y también ayuda a planificar.
  2. Conversación: es el núcleo de la historia; es platica que que se tiene con los usuarios, las notas, las grabaciones, los prototipos y los documentos.
  3. Confirmación: el criterio que se utilizara en las pruebas de aceptación que el usuario va a realizar 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).

El modelo INVEST y la historia de usuario (Scrum)

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 difícil 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 se puede probar, 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

  1. deben ser independientes entre si;
  2. se debe poder negociar los detalles entre los usuarios y los desarrolladores;
  3. las historias deben tener valor para el cliente;
  4. deben ser lo suficientemente claras para que los desarrolladores puedan estimarlas;
  5. deben ser pequeñas; y
  6. deben poder probarse usando los casos de prueba pre-definidos.
Comparte
  • 7
    Shares