Lo que debemos saber sobre las Historia de Usuario

La mayoría de manuales de Scrum describen la historia de usuario como una representación de una funcionalidad del producto que vamos a desarrollar pero, ¿tenemos claro cómo debe ser una Historia de Usuario?

Todos conocemos la fórmula:

Yo, como <rol> quiero <funcionalidad> para <beneficio/aporte de valor>

Ejemplo: Yo como huésped quiero ver las ofertas de alojamientos para poder elegir la que más me convenga.

Dicho de otra manera, quién, qué y para qué, pero no se trata el cómo. Por tanto, las cuestiones técnicas no pueden ni deben formar parte de una historia de usuario, para ello cada historia de usuario tiene sus tareas asociadas. Por esto, las historias están en el Product Backlog y son responsabilidad de Product Owner, y las tareas están en el Sprint Backlog y son responsabilidad de los desarrolladores. Es por esto también que, en una historia de usuario suelen trabajar más de una persona (funcionales, desarrolladores, testers), mientras que en las tareas suele trabajar una sola persona.

Otra cuestión importante a tener en cuenta es el tamaño de la Historia de Usuario, como sabemos, no debe contener demasiada información (debe caber en una tarjeta/pos-it) ya que recordemos no es un requisito. Si bien su redacción debe tener la información justa para conocer la funcionalidad a implementar, es también el vehículo que nos lleva a caer en la cuenta de otras necesidades para el producto, nos invita a pensar en sinergias y dependencias continuamente.

Una vez que tenemos claro qué debe contener una historia de usuario, ¿cómo sabemos que está lista para ser implementada? Según la Scrum Guide, la definición de hecho (DoD) es una descripción formal del estado del Incremento cuando cumple con las medidas de calidad requeridas para el producto. Aunque esta cuestión pueda resultar algo abstracta podemos aterrizarla en, por ejemplo, que el producto cumpla con éxito con los escenarios de pruebas planificados, la inexistencia de defectos detectados en herramientas como Sonar o Code Inspector…etc.   Por esto podemos decir que, la definición de hecho aporta transparencia, y proporciona al equipo una visión real del estado del producto y si este está listo para ser liberado.

Autora del artículo

Maria Dolores Pinal de Castilla, senior delivery consultant de Consultoría Tecnológica de Deloitte