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: el desconocido y olvidado

Desde hace tiempo tengo la sensación que se desconoce la función de un Product Owner.

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.

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.

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?

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.

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.

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.

Entender a los Equipos Scrum desde las Métricas

En nuestro trabajo diario con los equipos Scrum, es importante entender qué está ocurriendo sprint a sprint, y en qué lugares debemos poner el foco de las acciones de mejora de los equipos. También es importante disponer de datos objetivos, que en las sesiones de retrospectiva o de revisión del proceso, nos ayuden a tomar decisiones basadas en la realidad, y no en sensaciones u opiniones subjetivas.

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

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...

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