Es importante usar 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.

Historias de Usuario

¿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…

También te puede interesar.

¿Quién debe priorizar el Product Backlog en Scrum?

Agile y Scrum nacen principalmente del mundo del Software, aunque en los últimos años se han llevado a otros ámbitos de las empresas. Scrum plantea al Product Owner como una única persona. La realidad de la empresa nos empuja a implementar algún tipo de escalado de Scrum, en el que aparecen, de una forma y otra, Product Owners de Product Owners. ¿Significa esto que se está haciendo una mala implementación de Scrum? ¿O nos estamos adaptando a las necesidades tal y como indica Agile? ¿Tiene que de verdad ser una única persona? ¿O hay otras posibilidades manteniendo la cultura Agile?

En que punto del proceso consideramos el Producto como Entregable

Escoger dentro de nuestro proceso de generación de producto entregable el punto adecuado, puede ser muy complejo cuando dependemos de terceros.

Plan para formar a Scrum Master propios de la empresa

En todo acompañamiento en la transformación a la agilidad con Scrum, llega un momento en que los Agile Coach y Scrum Master externos a la empresa deben dejar al Cliente que siga su camino. Y con garantías de que no se va a perder lo conseguido y se va a seguir fomentando la mejora continua y el customer centric.

Lo que te estás perdiendo por hacer «tu» Scrum

¿Qué ocurre si decides utilizar sólo parte de Scrum? Dejar de usar roles, eventos o artefactos tiene sus riesgos.

Monta equipos Scrum de éxito

Cómo montar equipos Scrum de éxitoYa sabes lo que es un equipo Scrum. Es hora de dar un paso adelante y entender cómo montar un equipo Scrum de éxito. ¿Qué tipo de perfiles incorporas? ¿Cómo se balancean? ¿Cuándo les incorporas? Son preguntas que probablemente te...

Cómo facilito una retrospectiva si no soy Scrum Master

Una buena retrospectiva da la oportunidad al equipo de analizar su funcionamiento y establecer mejoras. Te dejamos consejos para facilitarla.

Ventajas de aplicar el Lead Time en los Equipos Scrum

En ocasiones, cuando arrancamos con los Equipos Scrum, nos encontramos con un par problemas habituales: el tamaño de los PBIs y que trabajan en paralelo en todas los PBIs del sprint. Hoy te traigo una solución que hemos puesto en marcha en algunos Equipos Scrum de nuestros clientes.

Cómo mejorar tu Scrum Daily

En ocasiones nos encontramos con equipos en los que la Scrum Daily se ha convertido en un evento individualista donde cada miembro del equipo de desarrollo comenta las tareas realizadas durante el día anterior, muchas veces con cierto carácter de reporte. Sin embargo, la daily es un evento colectivo donde a través de la inspección y adaptación se traza un plan de trabajo del día para el equipo.

El uso de las Métricas para saber nuestro nivel de Incertidumbre

Scrum nos ayuda a manejar la incertidumbre. Pero ¿cómo sabemos que lo estamos consiguiendo? ¿Qué métricas pueden ayudarnos a confirmar que tenemos bajo control la incertidumbre?

Apoya a tu equipo entendiendo qué le ocurre

La transparencia es uno de los pilares de Scrum. Con ella conseguimos hacer visible lo que ocurre dentro del producto, equipo, personas, … para hacer inspección y adaptación. ¿Cómo podemos saber qué ocurre en el equipo para poder apoyarle?

0 comentarios

Enviar un comentario

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

Aceptarás nuestra política de cookies si continúas navegando.

ACEPTAR
Aviso de cookies