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.

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

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

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

El Product Owner: el desconocido y olvidado

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

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.

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.

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?

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.

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.

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.

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