Conoce el Product Backlog
¿Qué es el Product Backlog y cómo se organiza? Recomendaciones a la hora de ordenar PBIs y hacer refinamientos.
"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 básicamente un listado de ítems (Product Backlog Ítems, PBIs) que representan las características del producto a construir por el Equipo Scrum. 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.
Objetivo del Producto y visión de 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.
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.
Ordena el Product Backlog
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.
Hacemos una distinción deliberada entre priorizar y ordenar. Muchas veces, 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.
Este ordenamiento es responsabilidad exclusiva del Product Owner y, aunque todos dentro del equipo pueden hacer sugerencias o recomendaciones, es el PO 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.
- Comunicación del progreso a los Stakeholders para calmar ansiedades y despertar su involucramiento.
- Diferenciar Product Discovery de Product Delivery y comprender el valor de cada uno.
- Segmentar tu universo de consumidores o usuarios para empatizar e identificar necesidades profundas de cada uno.
- Conocer los criterios para ordenar el Product Backlog según la estrategia y fase del ciclo de vida en la que se encuentra.
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.
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.
El Principio de Pareto
Wilfredo Pareto nació en 1848 en Italia. 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 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 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, los que 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 tentativos 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 llevado 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, fomentamos 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 susceptibles de ser alterados o reemplazados.
- Comunicación del progreso a los Stakeholders para calmar ansiedades y despertar su involucramiento.
- Diferenciar Product Discovery de Product Delivery y comprender el valor de cada uno.
- Segmentar tu universo de consumidores o usuarios para empatizar e identificar necesidades profundas de cada uno.
- Conocer los criterios para ordenar el Product Backlog según la estrategia y fase del ciclo de vida en la que se encuentra.