¿Eres Product Owner y no sabes cómo representar los elementos que vas a incorporar en el Product Backlog? ¿Cómo puedes verificar que el producto que se está construyendo está de acuerdo con las expectativas esperadas? Desde FeedBackGround queremos recomendar el uso de las historias de usuario, como una herramienta para facilitar la interacción con el cliente y la colaboración con el equipo, ¿entramos en detalle?
El Product Owner es el encargado de maximizar el valor que aporta el equipo en el menor tiempo posible, responsable de gestionar y priorizar el Product Backlog y por tanto, de cada uno de los elementos o PBI – Product Backlog ítems – que lo componen.
Entre sus responsabilidades recae que los PBI estén suficientemente detallados para que sean fáciles de comprender por parte del equipo, que los Stakeholder puedan contrastar que el detalle escrito cubre las necesidades expresadas y para que, una vez se haya realizado su implementación, se pueda comprobar fácilmente que satisfaga todo lo solicitado.
La escritura de ese detalle de funcionalidad se puede realizar usando Historias de Usuario. El Product Owner será principalmente el que las escriba, aunque también puede delegar la escritura y validación a los usuarios y StakeHolder teniendo en cuenta que él es el máximo responsable de esos elementos.
Historia de Usuario (HU)
Una historia de usuario se puede representar como una tarjeta que contiene una descripción corta de una funcionalidad, comentada desde la perspectiva de la persona que necesita esa funcionalidad, una indicación de a qué usuario o un cliente va dirigida y el por qué se solicita.
Escrito en lenguaje natural, para que lo pueda entender el StakeHolder, puede contener otra información como los criterios de aceptación.
Cada una de esas HU se almacenan en el Product Backlog, y contiene parte de la necesidad del cliente, características, funcionalidades, propiedades o aporte de valor al producto final. Están escritas des del punto de vista del Qué y del Por qué no desde el Cómo se va a solucionar.
La implementación de las HU se realiza en tareas, que se detallan durante el Sprint Planning, son la unidad de tamaño más pequeña necesaria para completar una historia, tienen propietario asignado y están estimadas. Una historia tiene uno o muchos criterios de aceptación y está completa cuando satisface sus criterios de aceptación.
Una buena HU debe satisfacer el modelo INVEST:
- Independent: No debe depender de otras historias.
- Negotiable: Los detalles se obtienen a partir de la conversación, el contenido es adaptable.
- Valuable: Una historia de usuario tiene valor para el cliente o el usuario.
- Estimable: Es posible determinar su tamaño, así como priorizarla respecto a las otras. Si es demasiado grande se dividirá en varias partes antes de que esté presente en el sprint bakclog.
- Small: Una vez refinada debe ser lo suficientemente pequeña para que se pueda implementar en una iteración o Sprint.
- Testeable: Se puede probar, debe cumplir los criterios de aceptación indicados.
El Uso de las HU aporta al Product Owner la posibilidad de adquirir conocimiento sobre el producto para explicar qué parte se está cubriendo con esa historia, evita pensar en la solución ya que se centra en el Qué y no en el Cómo, ayuda a transmitir al equipo de desarrollo la definición del producto con más detalle, con lo que los refinamientos serán más efectivos.
¿Quieres profundizar más sobre las Historias de Usuario o herramientas que ayudan al Product Owner? En FeedBackGround estaremos encantados de ayudarte, ¡contáctanos!
