, ,

Historias de Usuario ¿Por qué?

Historias de Usuario

Las Historias de Usuario son la forma, dentro de la prática Scrum, que más animan a utilizar los Scrum Master y Agile Coaches a los Product Owners, a la hora de escribir los Product Backlog Items, que conforman el Product Backlog. Pero, ¿por qué es interesante para un Product Owner novato utilizar historias de usuario?

¿Qué son?

Cuando nos cuentan a los Product Owner que es una historia de usuario, lo más habitual es que nos digan que es “la promesa de una conversación sobre el producto a construir” y/o “describe una parte del producto que puede construirse en una iteración”. La definición exacta y muy bien explicada puede encontrarse en muchas páginas de internet, por ejemplo en User Stories by Mountain Goat, así que os ahorro volver a leerla.

La fórmula de una historia de usuario es la siguiente:

 

CÓMO <persona> QUIERO <hacer algo> PARA <cubrir una necesidad>

 

Es bastante simple, y con un poco de práctica es fácil escribir todo nuestro backlog de esta manera.

¿Por qué usarlas?

Las Historias de Usuario, más allá de la convesación que provoque, describen con más o menos detalle una parte del producto que estamos construyendo. Por lo tanto, cada historia contiene:

  • Parte de la NECESIDAD de mi Cliente
  • Aporte de VALOR al Producto final
  • Una o varias de las CARACTERISCAS o FUNCIONALIDADES o PROPIEDADES que tendrá el Producto final

Todo ello escrito desde el punto de vista del QUÉ y del POR QUÉ, no desde el CÓMO se va a solucionar.

¿Qué me aportan como Product Owner?

El hecho de escribir Historias de Usuario que contengan esas 3 partes, como Product Owner nos está empujando a que ocurran algunas cosas:

  • Adquirir conocimiento sobre el Producto, para explicar correctamente que parte se está cubriendo con la historia.
  • A evitar pensar en la solución y describirla. Me centro en el QUÉ y el POR QUÉ, no en el CÓMO. Los Product Owners que provienen de tecnología tieden a escribir la solución, ya que es lo que han hecho siempre.
  • Nos ayuda a ir por delante del Equipo de Desarrollo, en el entendimiento y definición del Producto, de forma que los refinamientos sean efectivos.

En definitiva, a tener que pensar en la necesidad de mi cliente y entender el producto que cubre esa necesidad.

¿Qué aporta a mi Product Backlog?

Las Historias de Usuario al orientarse a la necesidad y el producto, me ayudan a que mi Product Backlog (P.B. en adelante) parezca de verdad un P.B., y no una simple lista de cosas que hacer ahí puestas un poco a voleo, o que sea un gantt disimulado.

  • Cada historia es una parte del Producto, lo que ayuda a orientar mi P.B. a entrega de producto.
  • Cada historia contiene parte de la necesidad y aporta valor, lo que ayuda a poder priorizar mejor mi P.B. según valor aportado o necesidades de mi cliente.
  • El nivel de detalle y tamaño de las historias me ayudan a tener una mejor visión de producto a corto, medio y largo plazo. Incluso las Épicas  puedo escribirlas con esta fórmula.
  • La negociación con stakeholder, clientes, y grupos de interés para priorizar el P.B., se realiza sobre producto y necesidades, no sobre soluciones.

Todo ello hará que de cara a mis Clientes o Stakeholders, mi P.B. será autoexplicativo, y les mostrará mejor como se están cubriendo sus necesidades con el producto que estamos construyendo.

Conclusiones

Las Historias de Usuario son una forma más de escribir Product Backlog Items, elementos del P.B., dentro de las disponibles. Sin embargo a los Product Owners que estamos empezando nos servirán de mecanismo para interiorizar algunas de las responsabilidades que nos asigna Scrum, y principalmente nos ayuda a orientar nuestro P.B. a producto; sobre todo si provenimos de tecnología. Es un punto de partida, que llegado el momento podremos abandonar por otro sistema que nos sea más útil, o adaptar a nuestras necesidades.

Os animo a utilizarlas, no porque el coach o scrum master de turno se ponga pesado, o porque estén de moda y todo el mundo parezca que escribe historias cojonudas (que no lo hacen); si no por que os ayudarán en vuestro trabajo como Product Owner y al entendimiento del rol. Y si no al menos conseguirás que te dejen tranquilo…

Síguenos en
 
0 comentarios

Dejar un comentario

¿Quieres unirte a la conversación?
Siéntete libre de contribuir

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *