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.

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.

Cómo convivir con las incidencias en un Equipo Scrum

En los Equipos Scrum que desarrollan nuevo software y mantienen el ya existente, es muy habitual tener que lidiar con incidencias provocadas por el software en producción. Su gestión es complicada ya que interrumpen directamente nuestro plan para el sprint, y al producto ya priorizado en el Product Backlog.

La historia de scrum, su primera implementación

Actualmente Scrum es el marco de trabajo más utilizado para implementar modelos Agile. Hoy os contamos como era su primera versión.

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?

Mi estrategia de Onboarding como Scrum Master

Me incorporo a un equipo como Scrum Master, ¿¿por dónde empiezo??

Estoy seguro de que esta pregunta ha pasado por la cabeza de más de uno y de una cuando se ha enfrentado al reto de comenzar a trabajar en una nueva empresa o con un nuevo equipo. En este post quiero compartir una estrategia que yo he utilizado y me ha sido útil para abordar el proceso de onboarding.

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.

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

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.

Multiplica los resultados de tu Sprint Planning

Hoy es día de Sprint Planning. Miras hacia tu equipo y… sólo ves pacas de paja rodar de un lado a otro. ¿Qué ha pasado con tus compañeros? ¿Dónde se esconderán? ¡Te han dejado solo! Te traigo 5 consejos para multiplicar los resultados de tu Sprint Planning.

Sprint Review: más allá de la demo

La Sprint Review es el evento de Scrum donde se muestra el resultado del sprint. Una buena review te ayudará en la estrategia de producto.

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