La teoría nos dice que un Product Backlog está creado con las necesidades de un sólo producto, pero la realidad es que a veces nos encontramos con equipos que crean, mejoran y/o mantienen más de un producto. En este caso ¿cómo podemos ayudar al equipo a gestionar esta situación?


Trabajar con más de un producto no suele ser decisión del propio equipo, me arriesgaría a decir que nunca lo es, pero me podría equivocar 🙂 A veces, sin saber siquiera muy bien cómo, el equipo se ve envuelto en un torbellino de productos y prisas que nos llevan a tener tareas de todos ellos en el mismo Sprint, sin un Sprint Goal claro, y con futuros silos de conocimiento por que cada desarrollador trabaja en algo diferente. ¿Os suena? A mi me suena mucho, muchísimo… así que he probado algunas cosas que me gustaría compartir con vosotros para que las pudierais tener en cuenta y ver si os sirven.

Posibles orígenes de esta situación

Tal y como esté diseñada la organización

Un motivo por el que un equipo puede trabajar con diferentes productos puede ser la no adecuada priorización de un portfolio a alto nivel, que nos hace trabajar en varias cosas a la vez con el objetivo de sacar variedad de cosas, ya sea por probar muchas hipótesis, por cubrir temas legales, etc… Este suele se el motivo que da más dolores de cabeza a los Product Owners, pues ha de lidiar con distintos valores.

El tipo de producto en el que trabajemos

Otro motivo puede ser el trabajar con un producto tan grande que puede tener diferentes pequeñas iniciativas o mini productos que pueden ser desarrollados en paralelo (quizá para diferentes clientes si el producto se hace a medida). Además, tras crearlos, tienen un futuro mantenimiento, que junto a otras pequeñas iniciativas con las que el equipo puede innovar para aportar nuevas soluciones a necesidades del cliente, suelen hacer que el Product Backlog acaben teniendo diversidad de pequeños objetivos.


Seguramente haya más motivos, pero dados estos dos ejemplos, ya os podéis imaginar que esto existe… Además la cosa se puede complicar, y no tener un sólo Stakeholder sino varios, uno para cada producto.

La posible solución a trabajar con más de un producto

A continuación os explico dos posibilidades ante dos casos distintos para que podáis probarlas.

Cuando los Stakeholders son diferentes para cada producto

  1. Reunid a los Stakeholders y poned encima de la mesa todo lo que hay previsto hacer.
  2. Haced que ellos mismos expliquen cada una de las iniciativas y qué valor creen que eso puede aportar a la empresa.
  3. Seleccionad distintos criterios por los que ellos puedan evaluar cada una de las iniciativas, sean suyas o no. Nosotros elegimos los siguientes:
    • Expansión del negocio
    • Aumento de ventas
    • Compliance Requests (afectación de la marca, legalidad…)
    • Reducción de costes (coste operativo, eficiencia…)
  4. Añadid un peso a cada uno de los criterios en función de la estrategia que la compañía tenga en ese momento.
  5. Explicadles como evaluar, por ejemplo con puntos de historia, cada uno de los criterios para cada iniciativa
  6. Multiplicad cada valoración por su peso y sumadlo todo.
  7. Ordenad los valores de mayor a menor y tendréis priorizadas las iniciativas de distintos productos con los que trabajar.

El éxito de esta actividad dependerá del nivel de decisión que tengan los Stakeholders en su producto. E nuestro caso funcionó bien en un inicio, pero con el tiempo, los Stakeholders presentes en nuestras sesiones se veían presionados por sus responsables, que obviamente sólo miraban los resultados de su departamento, no de la empresa, eso hizo que dejaran de priorizar juntos para volver al método «quien se queje más fuerte irá antes». Pero tampoco podemos culparles por ello, recordemos que cuesta mucho adoptar una mentalidad agile a nivel de negocio (Business Agility) y se suele empezar la casa por el tejado, implementando la cultura sólo a nivel técnico.

Cuando tenemos a un único Stakeholder para todos los productos

Parece raro que con un solo Stakeholder tengamos problemas de priorización, pero puede haberlos si no tenemos un Product Goal bien definido. Tenerlo os puede salvar de esta situación.

El Product Goal es un objetivo a largo plazo, mayor que un Sprint, usualmente a varios Sprints vista. Este objetivo nos permite saber para qué estamos haciendo Sprints. Cada Sprint es una oportunidad de acercarnos al Product Goal y, de hecho, lo revisaremos en cada Sprint Review con stakeholders.

(https://mamaqueesscrum.com/2022/07/18/product-goal/)

Para definir el Product Goal os recomiendo usar cualquiera de las plantillas que corren por internet con este objetivo. Lo importante en este caso son tres cosas:

  • Definid bien, junto con los Stakeholders, qué queremos conseguir. No queremos un output, sino que hay que forzar a buscar el outcome. Por ejemplo, no nos sirve decir que queremos que X esté en producción el día D, tenemos que saber qué estamos buscando con X, qué pretendemos conseguir de cara al usuario.
  • Listad todos los productos mezclados en el Product Backlog y pensad qué aporta cada uno de ellos a ese objetivo final. Incluso podéis valorarlo como hemos hecho en el caso anterior (cuando teníamos diferentes Stakeholders). El objetivo es tenerlos priorizados.
  • Pensad en cómo vamos a medir cada uno de ellos cuando vayan saliendo a producción, para saber si estamos consiguiendo nuestro Product Goal o no, y modificad la prioridad si es necesario.

¿Tenéis más casos aquí no contemplados? Los podéis compartir en comentarios o bien hacédmelos llegar para pensar juntos nuevas soluciones.

¿Habéis probado otras soluciones para el mismo problema? Os invito a añadirlas a través de los comentarios para que sean útiles también para otros.

5 (1 votos)

Deja un comentario