El Product owner y el aporte de valor del product backlog

Uno de los problemas más habituales de los Product Owner, está en saber cuál es el valor que aporta a la empresa el producto que están construyendo. Os contamos desde nuestra experiencia como lo hemos afrontado.

¿Qué es el aporte de Valor?

No hay una definición concreta para lo que significa el aporte de valor de los elementos del Product Backlog (PBI en sus siglas en inglés). Puedes buscar en google, encontrar varias, y escoger la que más te guste o se ajuste a lo que necesites. Para mí es:

 Cuánto ayuda cada PBI a conseguir los objetivos estratégicos de la compañía y/o a cubrir las necesidades del cliente.

Desde mi punto de vista cualquier PBI que no esté asociado de una forma u otra a la estrategia de la compañía o a las necesidades de los clientes, no tiene sentido abordarlo. Incluso en un periodo de exploración o indagación, habrá un destino al que llegar, un objetivo que cumplir. Por eso considero que el valor de un PBI para la compañía es cuánto me acerca a ese objetivo.

 

Si quiero aumentar mis ventas un 10%, un PBI me llevará a conseguir el 1%, otro el 3%, otro un 0,5%; cada uno de ellos incrementará mis ventas y en el conjunto conseguiré el 10%.

Si quiero reducir el tiempo de la facturación mensual en 3 días, un PBI los reducirá un 1 día, otro unas horas, etc…

Si quiero incrementar las ventas, un objetivo estratégico, publicaré habitualmente entradas mi Blog para incrementar el tráfico,e indirectamente las ventas. Pero ¿cuánto contribuye esto al objetivo estratégico?

En un entorno ideal ésta sería la manera óptima de saber cuánto nos aporta cada PBI. Seguramente en empresas pequeñas sea viable. Pero ¿y en las medianas y grandes empresas? En éstas, conseguirlo puede suponer un esfuerzo mayor que el beneficio que aporta. Nos encontraremos con algunos problemas:

Cartera o Portfolio de iniciativas amplio

Seguramente nuestra cartera de proyectos o nuestro portfolio de iniciativas tendrá una gran variedad de objetivos diferentes: reducción de costes, aumento de ventas, satisfacción del cliente, retención de clientes, tráfico en mi web, …

Unificación de los Ojbetivos

Esa variedad de objetivos, que conceptualmente son diferentes, tendremos que unificarla de alguna forma para cuantificar el valor que aportan, con el esfuerzo que eso implica.

f

El reparto de los objetivos en cada PBI

Según vayamos dividiendo nuestros PBIs en otros más pequeños, supondrá un esfuerzo mayor establecer cuánto del objetivo global se va a conseguir. Puede llegar incluso a ser confuso y no ofrecerme ningún beneficio hacerlo.

¿Qué opciones tenemos entonces?

Obtener el aporte de Valor del Product Backlog

En uno de nuestros clientes estamos realizando una sesión bimestral, cuyo principal objetivo es la priorización del portfolio de iniciativas de Negocio sobre las que tiene que trabajar el área de Tecnología (IT). En esta sesión, IT junto con todas las áreas de negocio de la compañía, priorizan de manera consensuada los PBI a 3 meses vista. Utilizando como criterios de priorización los objetivos del negocio.

Hace unos meses implementamos una mejora en esta sesión para que, además de la priorización, dispusieramos de una cuantificación del valor aportado por cada iniciativa y las entregas en que se divide. Incorporamos a esta sesión un proceso, conceptualmente simple, para establecer el valor de cada PBI. Un sistema de puntuación basado principalmente, de nuevo, en el consenso entre áreas de negocio.

¿En qué consiste?

Lo primero será  establecer un escala de 4 ó 5 valores (no vamos a necesitar más) que nos ayuden a entender y diferenciar fácilmente que PBIs aportan más. Una puntuación más alta significa más valor. Esta es la parte fácil.

1

5

8

13

21

Para establecer el Valor de cada PBI lo haremos a través del debate y el consenso entre las áreas de negocio. El proceso es, más o menos, así:

  1. El área solicitante expone y describe al resto la iniciativa asociada al PBI: la necesidad y los objetivos de compañía.
  2. Con esa información, su conocimiento y experiencia, entre todas las áreas establecen, mediante el debate, la puntuación de la escala que le corresponde. Es importante hacerlo en relación a las que ya están puntuadas.
    • Respecto a los que ya tenemos puntuados ¿a cuál se parece en aporte de valor? ¿Aporta más? ¿Aporta menos? ¿Cuánto más o cuánto menos?
  3. Iremos colocando cada PBI en la puntuación que se acuerde, e incluso ajustando las ya existentes según se incorporan las nuevas.

Al finalizar la sesión tendríamos una distribución PBI por aporte de valor:

1

5

8

13

21

PBI 1

PBI 3

PBI 2

PBI 6

PBI 4

PBI 7

PBI 8

PBI 5

Al tratarse de una sesión que se realiza de forma periódica, se puntúan los nuevos PBIs cada vez y ser revisan aquellos que disponemos de nuevo información. De esta forma, todo sobre lo que vamos a trabajar en los equipos Scrum, tendremos identificado el valor que aporta.

Es probable que te parezca una sesión costosa y difícil de agendar, sin duda. Te garantizo que resulta mucho más rentable que trabajar en elementos de baja importancia y sin un consenso previo.

 

Beneficios de disponer del aporte de Valor del Product Backlog

Hay una amplia variedad de beneficios, os enumeramos los más relevantes:

Somos capaces de medir el producto que entregamos por el valor que tiene para la compañía, en lugar de hacerlo por la cantidad o por los puntos de historia. Dejará de ser relevante entregar 5 ó 10 PBI, ó 35 ó 100 puntos de historia por sprint. Lo relevante será el incremento de valor del producto.

Podremos realizar proyecciones a futuro, usando el Burn Up, basándonos en el valor que queremos conseguir. Nos posibilita determinar cuánto queremos incrementar en cada sprint, cada trimestre, cada año fiscal, el periodo que consideremos adecuado, el valor del producto.

Priorizar e ir adaptando nuestro Product Backlog para conseguir el incremento de valor que hayamos establecido. Si unimos el coste que nos supone construir el producto (puntos de historia, el coste del Equipo Scrum, …) con el valor que aporta, tenemos un sistema muy sencillo para priorizar nuestro Product Backlog.

Basar nuestro nivel de predictibilidad y adaptabilidad en el la combinación del aporte del valor y nuestra capacidad de entrega, y no de sólo en este último.

Como compañía me permitirá medir el valor que aporta el área de IT al negocio de manera objetiva, entender mejor si las soluciones que nos está facilitando para cubrir las necesidades del negocio y del cliente, aportan el valor que espero. Me permite tener un lenguaje común con el que negociar qué debe hacerse primero, no sólo desde la complejidad técnica de la solución, sino también desde la importancia para el negocio.

También te puede interesar

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.

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.

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.

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.

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.

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

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?

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

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.

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