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

El Product Owner y su relación con los Stakeholders

Como Product Owner enseguida te has dado cuenta de la gran importancia que tiene tu relación y la del Equipo Scrum con los Stakeholders.

Como empezar como Scrum Master

Acompañar a equipos es una gran responsabilidad pero es muy gratificante. Cada persona y cada equipo tiene unas necesidades diferentes en función de su realidad. Sin embargo, bajo nuestra experiencia, estos consejos pueden servirte para iniciarte como Scrum Master en un equipo.

Burndown y Burnup para el Scrum Master

Como Scrum Master puedes obtener información muy valiosa analizando estos dos gráficos para entender lo que está ocurriendo en tu equipo.

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.

Por dónde empezar como Product Owner que viene de Tecnología

Estás dando tus primeros pasos como Product Owner, tras haber pasado años diseñando y desarrollando software. Te enfrentas a varios dilemas.

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.

Es importante usar Historias de Usuario

Usar Historias de Usuario es importante para los Product Owner, además de la más utilizada a la hora de escribir el Product Backlog.

Aprendiendo en un Equipo Scrum

El conocimiento compartido potencia a tu equipo. Aquí descubrirás cómo identificar las áreas de conocimiento y favorecer su aprendizaje continuo

Scrum para disipar incertidumbre

Scrum es un marco que te puede servir para hacer lo mismo de siempre a trocitos. Sin embargo, puedes utilizar Scrum de manera inteligente y sacarle toda su potencia. ¿Cómo? Orientándolo a generar certezas sobre tu producto o tu mercado.

Definition of Ready y Definition of Done

¿Qué necesitas para poder comenzar una tarea? ¿Cuándo podemos dar una tarea por terminada? Para resolver estas dudas, en este vídeo te traemos el Definition of Ready y el Definition of Done

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