Publicado: en Guías de Agilismo

Historias de Usuario

Palabras clave:
Tiempo aproximado: 2 min.

“CCC: Card, Conversation, Confirmation”
Ron Jeffries

DEFINICIÓN: Una historia de usuario (o user story en inglés) describe una funcionalidad que, por sí misma, aporta valor al usuario.

Se compone de:

  • una descripción escrita de la historia usada como recordatorio y para planificar. (Debe ser breve)
  • conversaciones acerca de la historia que sirven para aclarar los detalles
  • un criterio de aceptación (idealmente automatizado) que permita determinar cuándo la historia ha sido completada

Una vez estimadas y priorizadas pasan a formar parte de la pila de producto (product backlog).

Formato

Podemos usar tarjetas grandes para las historias de usuario y tarjetas pequeñas (o post-its) para destacar tareas importantes que no deben olvidarse durante el desarrollo de una “tarjeta grande”.

Es aconsejable usar el formato: “Como [rol] quiero [funcionalidad] para [beneficio]”

Como [cliente habitual], quiero [ver productos relacionados con mis compras anteriores] para [ver si hay otros productos que me puedan interesar].

Los criterios de aceptación suelen anotarse en el reverso de la tarjeta.

INVEST

  • Independent : se pueden hacer en cualquier orden (no dependen unas de otras)
  • Negotiable : no son contratos, sino promesas de comunicación
  • Valuable : siempre debemos dar valor al cliente (no crear historias técnicas)
  • Estimable : si no podemos estimarlas es porque debemos conversar más
  • Small : pequeñas (pero no demasiado)
  • Testable : si no puedes probarla, ¿cómo puedes saber que está acabada?

En nuestro ejemplo, los criterios de aceptación se pueden expresar como restricciones:

  • Los productos estarán ordenados por valoración y margen de beneficio.
  • Cuando el usuario haga clic en un producto, se desplegará el detalle.
  • Etc.

Las restricciones que acordemos pueden influir mucho al coste de construcción.

Malas prácticas:

  • Escribir historias que dicen cómo se hará en vez de qué se debe hacer (p.ej. CRUD de Clientes)
  • Una Historia de usuario no es un Caso de uso porque no se centra en el cómo ni tampoco es una definición exhaustiva de los requisitos.
  • No escribir el criterio de aceptación o no ser suficientemente explícito.
  • No estimar una tarjeta puede crear falsas expectativas y dificulta la autodisciplina.
  • Fiar todo a lo escrito en la tarjeta: a veces es necesaria documentación externa. (Wiki)
  • Dar una historia por hecha cuando está “prácticamente hecha” en vez de “hecha-hecha”.

Bibliografía

Temas avanzados:

En mi blog:

PUBLICIDAD:

Si estás interesado en recibir formación, puedes leer sobre los servicios que ofrezco o ponerte en contacto conmigo.