Artefacto: Product Backlog

El Product Backlog es una lista emergente y ordenada de lo que se necesita para mejorar el producto. - Guía de Scrum

El Backlog del Producto es básicamente un listado de ítems (Product Backlog Ítems, PBIs) que representan las características del producto a construir. Esta lista de PBIs es un elemento vivo y emergente, que cambia constantemente a medida que aprendes más y más acerca del producto. Es mantenida y ordenada por el Product Owner y es la única fuente del trabajo que hace el Equipo Scrum.

Todos los PBIs que componen el Product Backlog tienen una razón de existir, y esa razón es cumplir con cierto Objetivo de Producto.

Visión de Producto

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?

A la fecha, Scrum no hace referencia a una visión de producto, por lo que no podemos decir que sea un artefacto de Scrum, aunque es muy recomendable contar con ella. 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 si no es que utópicas. Para poder medir tu progreso hacia la realización eventual de la visión de producto, debes determinar una consecución de Objetivos de Producto.

Objetivo del Producto

El Objetivo del Producto sí está definido dentro de Scrum. Es un hito futuro que deseas lograr a través del producto, pero no mide alcance sino resultado. Por ejemplo: incrementar un 200% las suscripciones de clientes de Asia a las categorías Plus y Premium.

El camino hacia la visión de producto podrá contar con una serie de objetivos de producto diferentes a lo largo del tiempo. Tu Equipo Scrum deberá alcanzar un objetivo (o abandonarlo) antes de perseguir el siguiente.

Ordena el Product Backlog

Como te comenté antes, todos los PBIs del Product Backlog existen para lograr un cierto Objetivo de Producto. Dar un orden claro a los PBIs es esencial porque justamente este orden determinará la estrategia de evolución del producto y las prioridades con las cuales los desarrolladores transformarán los PBIs en Incrementos de producto.

Hago una distinción deliberada entre priorizar y ordenar. En mis años de experiencia he visto que cuando se habla de priorizar, una opción es acomodar el todo en tres grandes grupos: prioridad alta, media y baja. A diferencia de eso, los PBIs de un Product Backlog deben estar en una fila, nunca compartiendo un mismo grupo, salvo ciertas excepciones que ya veremos, por eso me refiero a ello como "ordenados" en fila.

Este ordenamiento es responsabilidad exclusiva del Product Owner y, aunque todos dentro del equipo pueden hacer sugerencias o recomendaciones, es el Product Owner quien tiene la última palabra acerca del orden definitivo de los ítems del 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 planteáramos 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 abonando con tarjeta de crédito de forma telefónica o por transferencia bancaria.

Ordenado por retorno de la inversión (ROI)

Un enfoque diferente 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 identificada, 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 en forma 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, descubriendo 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 agilidad, 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.

El Principio de Pareto

Wilfredo Pareto nació en 1848 en Italia, donde creció formando parte de la clase media alta. Fue un reconocido 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 el 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% remanente).

Aplicando 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

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