"El Product Backlog es una lista emergente y ordenada de lo que se necesita para mejorar el producto." - Guía Oficial de Scrum
El Backlog del Producto es esencialmente un listado de ítems, conocidos como PBIs, que representan las características del producto que será construido por el Equipo Scrum. Esta lista de PBIs es un elemento vivo y evolutivo, que se transforma continuamente a medida que se adquiere mayor aprendizaje sobre el producto. Es responsabilidad del Product Owner mantener y ordenar este backlog, y es la única fuente del trabajo que hace el Equipo Scrum.
Cada PBI en el Backlog del Producto tiene una razón de ser, y esa razón es contribuir hacia un cierto Objetivo de Producto.
Objetivo del Producto y visión de Producto
El Objetivo del Producto está claramente definido dentro de Scrum. Representa un hito futuro que deseas alcanzar con tu producto, enfocándose no en el alcance, sino en el resultado deseado. Por ejemplo: lograr un incremento del 20% en las suscripciones de clientes de Asia a las categorías Plus y Premium.
El trayecto hacia la visión de producto puede involucrar una serie de objetivos de producto diferenciados en el tiempo. Tu Equipo Scrum deberá alcanzar un objetivo (o decidir abandonarlo) antes de perseguir el siguiente.
La visión del producto es la descripción del propósito del producto. Debería responder la pregunta ¿para qué lo quieres construir? o ¿qué quieres lograr?
Hasta ahora, Scrum no alude a una visión de producto, por lo que no se le considera un artefacto de Scrum, aunque es altamente recomendable tener una. Por ejemplo, la visión de Spotify es “Ser una plataforma cultural donde los creadores profesionales puedan liberarse de las limitaciones de su medio y donde todos puedan disfrutar de una experiencia artística inmersiva que nos permita sentir empatía entre nosotros y sentirnos parte de un todo mayor”. La visión de Google es “proporcionar acceso a la información del mundo con un solo click”.
¿Coincidimos en que ninguna de estas visiones se puede medir, ni tienen un horizonte temporal? De hecho, suenan ambiciosas o hasta utópicas. Para poder medir tu progreso hacia la realización de la visión de producto, debes determinar una consecución de Objetivos de Producto.
Ordena el Product Backlog
Todos los Product Backlog Items (PBIs) del Product Backlog se incluyen con el propósito de lograr un cierto Objetivo de Producto. Establecer un orden claro a los PBIs es esencial, ya que este orden guiará la estrategia de evolución del producto y las prioridades con las que los desarrolladores transformarán los PBIs en incrementos de producto.
Realizamos una distinción deliberada entre priorizar y ordenar. Muchas veces, cuando se habla de priorización, una opción es acomodar todo en tres grandes grupos: prioridad alta, media y baja. A diferencia de eso, los PBIs de un Product Backlog deben estar en una secuencia, nunca compartiendo un mismo grupo, salvo ciertas excepciones.
La responsabilidad de este ordenamiento recae exclusivamente en el Product Owner y, aunque todos dentro del equipo pueden ofrecer sugerencias o recomendaciones, es el PO quien tiene la última palabra acerca del orden definitivo de los ítems en el Product Backlog, teniendo en cuenta el contexto de negocio, el producto mismo y el mercado en el que está inserto.
Ordenado por aporte al objetivo del producto
Una forma en la que puedes ordenar los ítems del Product Backlog es según su aporte al objetivo del producto. Podemos entenderlo como la relevancia que un ítem tiene para el cumplimiento del objetivo del producto.
Si proponemos un ejemplo que ilustre el aporte de los PBIs con respecto al objetivo del producto, podríamos decir: en un producto cuyo objetivo es aumentar la afluencia de alumnos y facilitar la comunicación de los contenidos de las diferentes carreras de una universidad, se ha decidido crear un sitio web con diferentes características que se encuentran listadas en el Product Backlog. Dos de ellas son 1) que el alumno pueda acceder a los programas de estudios de las diferentes carreras y sus contenidos y 2) que el alumno pueda efectuar el pago en línea de su matrícula y cuotas utilizando una tarjeta de crédito.
En esta situación, podrías pensar que el PBI que representa el pago online con tarjeta de crédito tiene un aporte mayor al objetivo de producto que darle acceso a los alumnos a los contenidos de los programas de estudio, cuando la realidad es a la inversa: 1) el hecho de que un alumno pueda acceder a los contenidos de los programas de las diferentes carreras tiene un aporte mayor hacia el cumplimiento del objetivo del producto (aumentar la afluencia de alumnos e incrementar la comunicación de los programas) que lo que el pago online podría aportar y 2) un alumno podría seguir realizando pagos con tarjeta de crédito de forma telefónica o por transferencia bancaria.
Ordenado por retorno de la inversión (ROI)
Un enfoque alternativo que puedes emplear para determinar la prioridad de un ítem del Product Backlog es calcular el beneficio económico que se obtendrá en función del esfuerzo que se deba invertir. Esto, si bien es una simple fórmula matemática, tiene implícita la problemática de encontrar o conocer el valor económico ganado por la incorporación de una determinada característica a un producto. Una vez identificado, el cálculo es relativamente simple:
ROI = beneficio/costo.
Donde el costo representa el esfuerzo necesario para la construcción de una determinada característica de un producto y el beneficio es el rédito económico obtenido por su incorporación.
Ordenado por importancia y riesgo
Ya sea que ordenes los ítems del Product Backlog por aporte al objetivo del producto o por ROI, en cualquier caso, llamémosle “ordenar por importancia”, éstos pueden verse afectados por el nivel de riesgo asociado a cada uno de ellos.
De esta manera, deberías aprovechar la construcción iterativa y evolutiva de Scrum para mitigar riesgos de manera implícita: construyendo primero aquellos PBIs con mayor riesgo asociado y dejando los que poseen menor riesgo para etapas posteriores.
Se recomienda que los PBIs de baja importancia y alto riesgo sean evitados.
Alcance Variable
Dado que no te es posible conocer de manera anticipada el producto que debes construir para alcanzar los objetivos, es de esperar que vayas aprendiendo de los clientes, explorando el negocio y validando tus supuestos. Scrum es un viaje de descubrimiento que emprendes junto a tus clientes y, bajo este escenario, el Product Backlog debe ser un elemento vivo que se adapta constantemente, al ritmo de tu aprendizaje y del feedback frecuente.
Si bien, tradicionalmente, el alcance se ha intentado fijar desde el comienzo, y así manejar el costo y el tiempo como los elementos variables, desde la perspectiva ágil, esta ecuación se invierte: el tiempo y el costo son los componentes fijos del proyecto, mientras que el alcance es el componente variable, dado que es lo que no conocemos de forma anticipada.
Al aplicar este principio al desarrollo de productos, podrás encontrar que aproximadamente el 20% de las características de un producto resuelve el 80% de la necesidad que le da origen. Y, de manera recursiva, el 20% del 80% restante de las características, resuelven el 80% del 20% restante de la necesidad.
Manejo de Contingencias
Al aprovechar que el alcance es variable y que todo lo que se construye está ordenado en el Product Backlog según su aporte al objetivo del producto, vamos a utilizar los PBIs menos prioritarios como la contingencia frente a imprevistos. Esto quiere decir que, al respetar tiempo y costo, el alcance de menor prioridad sería el que pagaría el precio de retrasos o desvíos. Para que este enfoque sea eficaz, es fundamental la labor del Product Owner y su habilidad para facilitar el descubrimiento de las prioridades por parte de todos los involucrados.
El Principio de Pareto
Wilfredo Pareto nació en 1848 en Italia. Fue un renombrado ingeniero, sociólogo, economista, político y filósofo. Uno de sus estudios más reveladores, en aquella época, dejó al descubierto que el 80% de las tierras de Italia pertenecían al 20% de la población.
A partir de ese descubrimiento, varios matemáticos y economistas derivaron esas observaciones y las verificaron en otros ámbitos. Uno de ellos fue Joseph Juran, quien en 1941 planteó el Principio de Pareto (o regla del 80/20) aplicado a la calidad: el 80% de los efectos son producidos por el 20% de las causas. Esta ley también se conoció como el principio de los Pocos Vitales (el 20% principal que genera el 80% más importante) y los Muchos Triviales (el 80% restante que genera el 20% restante).
Refinamiento del Product Backlog
"El refinamiento del Product Backlog es el acto de dividir y definir aún más los PBIs en elementos más pequeños y precisos." - Guía Oficial de Scrum
El refinamiento del Product Backlog no es un evento formal de Scrum sino una actividad. Esto significa que en el framework no hay una reunión específica dedicada a ello. Esta actividad es coordinada de forma autogestionada por el Equipo Scrum, quienes deciden quiénes, cuándo y durante cuánto tiempo realizan el refinamiento del Product Backlog.
Durante el refinamiento revisas los PBIs tentativos de Sprints futuros, pero no de muchos Sprints futuros porque estarías anticipándote demasiado sin haber validado necesidades reales e invirtiendo demasiado esfuerzo en PBIs de baja prioridad con posibilidad de ser descartados. Por eso refinarás no más de tres o, como mucho, cuatro Sprints futuros.
Una recomendación es invitar a quienes identifiques como actores claves de tu audiencia a participar del refinamiento. Estos podrían ser stakeholders, usuarios, clientes, consumidores, etc.
Recuerda que esos PBIs, aunque refinados, siguen siendo provisionales y podrían cambiar en orden y necesidad, por lo que no hay garantías que se lleven a cabo en los Sprints previstos, por eso los llamamos “tentativos”.
Un Product Backlog eficiente
Cuando hablamos de eficiencia, hablamos de obtener el mayor beneficio con el menor esfuerzo posible. Este concepto, aplicado al Product Backlog, significa invertir el esfuerzo de exploración y profundización de la manera más inteligente posible para evitar retrabajos y desperdicios. Por esto, desde Alaimo Labs promovemos un Product Backlog donde sus PBIs más prioritarios están expresados con un nivel de detalle mucho mayor que los PBIs de menor prioridad, los cuales están descritos a un nivel más alto, ya que son los más propensos a ser alterados o reemplazados.
Continúa aprendiendo...
- Guía de introducción a Scrum
- El trabajo del Product Owner en el desarrollo ágil
- Los procesos de seguimiento y control vs. los procesos de Scrum
