¿Qué es el PRODUCT BACKLOG?

El Product Backlog (o «Lista de Producto» en español) es una lista emergente y ordenada de todo lo que se conoce que es necesario que un producto o servicio cumpla.
Es uno de los 3 artefactos de Scrum. También es la única fuente de requisitos para cualquier cambio.

El Product Backlog es emergente, es decir, nunca está completo sino que es dinámico; cambia constantemente para identificar lo que el producto necesita para ser competitivo y útil en el mercado que se encuentra.

¿Qué contiene el Product Backlog?

Este artefacto contiene todas las características, funcionalidades, mejoras y correcciones (o bugs) a realizarse sobre el producto o servicio. A cada elemento del Product Backlog se lo conoce como Product Backlog Item (PBI) y tiene una descripción, un orden y una estimación. A medida que el producto es utilizado, el mercado comienza a proporcionar retroalimentación y esto hace que se convierta en una lista más larga y detallada. Por esto podemos decir que es un artefacto vivo ya que constantemente los requisitos están cambiando.

¿Quién es el responsable del Product Backlog?

El responsable del Product Backlog es el Product Owner, incluyendo su contenido, disponibilidad y priorización.

El compromiso del Product Backlog: El Product Goal

Como todos los artefactos en Scrum, el Product Backlog también contienen un compromiso asociado. El compromiso del Product Backlog es el Product Goal (u «Objetivo del Producto» en español).

El Product Goal describe un estado futuro del producto que puede servir como un objetivo para que el Scrum Team planifique. El Product Goal está en el Product Backlog. El resto del Product Backlog emerge para definir «qué» cumplirá con el Objetivo del Producto.

En la guía Scrum 2020 podemos encontrar la siguiente declaración:

Un producto es un vehículo para entregar valor. Tiene un límite claro, personas interesadas conocidas, usuarios o clientes bien definidos. Un producto puede ser un servicio, un producto físico o algo más abstracto.

Cada Sprint debería acercar el producto al Product Goal. El progreso hacia el Product Goal se analiza durante la revisión del Sprint.

El Objetivo del Producto es el objetivo a largo plazo del Scrum Team. Ellos deben cumplir (o abandonar) un objetivo antes de asumir el siguiente.

¿Quién estima los ítems del Product Backlog?

Los Developers son los responsables de proporcionar todas las estimaciones. El Product Owner podría influenciar al Equipo ayudándoles a entender y seleccionar el Objetivo del Sprint,
pero las personas que harán el trabajo son las que hacen la estimación final. Dejar que las personas comprometidas con el trabajo real hagan la estimación. En el sentido de Scrum, son los cerdos los que estiman, no las gallinas. Recordemos el patrón de Estimación Ágil: Los Cerdos Estiman.

Ejemplo de un Product Backlog

 

¿Cómo priorizar el BACKLOG?

El Product Owner ordena los PBI en busca de generar ROI (retorno de inversión) a largo plazo. Para ello debe considerar tanto los ingresos como los costos de cada ítem. El Product Owner, dueño del producto, tiene el poder para tomar decisiones en nombre de todos los stakeholders, aunque debería considerar todas las ideas y pedidos para de todos ellos para equilibrar la ecuación de valor.

Me parece interesante aclarar en este punto que el ROI no tiene que ser solo relacionado al dinero, sino que se trata de valor: El valor no solamente es el que comúnmente escuchamos refiriéndose al que se basa en la teoría económica del valor: intercambiar un activo por otro de igual valor.

Una empresa también puede valorar la retención de los empleados, las buenas relaciones con los clientes, una buena imagen pública o muchos otros objetivos que quedan fuera de la teoría económica del valor.

Considerando esto, podemos decir que el Product Owner debe ordenar la lista de manera tal que queden arriba los ítems que aportan mayor ROI y hacer esos primero.

 

High-Value-First

¿Qué son las User Stories?

Las User Stories (o «Historias de Usuario» en español) es uno de los formatos más utilizados para redactar los Product Backlog Items (PBIs). Contienen descripciones cortas de un requerimiento escritas desde el punto de vista de la persona que lo está solicitando que por lo general es un Stakeholder o un cliente. Está compuesta por tres partes principales:

Como <tipo de usuario>, quiero <algún objetivo> para <alguna razón/propósito>.

Ejemplo:

El objetivo de usar historias escritas de esta manera es crear una conversación cara a cara sobre lo que se necesita del usuario final.

 

Criterios de aceptación

Una User Story también puede tener criterios de aceptación, que son las condiciones de satisfacción que ayudarán a los Developers a crear la mejor solución y poder determinar los límites del requerimiento.

Ejemplo:

  • La notificación tiene que ser legible desde un teléfono celular.
  • Debe expresar claramente si ese resultado significa «Aprobado» o «Desaprobado».
  • También debe incluir un enlace para ir a ver el examen en formato digital.

Principios INVEST

Los principios o criterios INVEST son una lista de 6 cualidades que nos ayudan a comprobar la calidad de una User Story:

«I»ndependent (independiente): Debe ser independiente de otras historias.
«N»egotiable (negociable): Su alcance y criterios deben ser variables. Los Developers deben poder negociar con el Product Owner estos criterios al comienzo del Sprint.
«V»aluable (valorable): Deben aportar valor real al cliente, un incremento de producto completo.
«E»stimable (estimable): Deben poder estimarse por los Developers por lo cual no deben ser demasiado grandes y debemos tener cierto conocimiento de esta a nivel negocio y técnico.
«S»mall (pequeña): Debe poder completarse dentro de un Sprint.
«T»estable (comprobable): Debe ser posible verificar que la misma está completa una vez desarrollada. Para ello debe tener claros criterios de aceptación con los cuales verificamos que esté realmente lista.

¿Cómo gestionar el Backlog con varios equipos?

Es común que varios Equipos Scrum trabajen juntos en un mismo producto. En estos casos los equipos trabajan sobre un único Product Backlog y para agrupar elementos de la lista por similitudes se suelen agregar etiquetas o atributos.

¿Qué es el Definition of Ready?

El Definition of Ready «DoR» (o Definición de Listo) es un acuerdo del Equipo Scrum para determinar si un elemento está apto para ingresar a un Sprint.

Al contrario del Definition of Done, que se aplica a elementos dentro de un Sprint en curso, el Definition of Ready apunta a elementos que están por entrar en el Sprint. Si los Developers no comprenden correctamente los PBIs el tiempo de desarrollo dentro del Sprint tiende a subir mucho y pone en peligro el cumplimiento del Objetivo del Sprint; por lo que es muy importante que se genere este acuerdo se cumpla, es decir, que no entren al Sprint PBIs que no están en estado «Ready».

Podemos decir que el Product Backlog esta «Ready» cuando tiene suficientes PBIs en su parte superior para llenar un Sprint y que están en «Ready».

¿Qué es el Release Plan?

El Release Plan (o Plan de Lanzamiento) es un plan que utilizamos para predecir cuándo podremos lanzar al mercado un conjunto de Incrementos de Productos que tendremos de varios Sprints con un suficiente valor para cumplir un objetivo de negocio.

Una de las preguntas que más escuchamos en cualquier proyecto es ¿cuándo va a estar listo? En cualquier momento debe ser posible calcular el trabajo total restante que hay que hacer para alcanzar el objetivo. El Product Owner es el responsable de hacer este seguimiento y lo realiza al menos una vez por Sprint en cada Sprint Review.

Para ello revisa las estimaciones de los Developers provistas para los elementos del Product Backlog y puede agrupar dichos elementos por Objetivos en base a la velocidad de su equipo. Esta información se muestra de forma transparente a todos los interesados.

Release Burndown

burndown-release-plan


Si bien se ha demostrado que varias prácticas de proyección para predecir el progreso como el burn-down y burn-up release y el flujo acumulado son muy útiles no reemplazan la importancia del empirismo. En entornos complejos se desconoce lo que ocurrirá. Solo lo que ya ha ocurrido puede utilizarse para la toma de decisiones.

El PRODUCT BACKLOG y el SPRINT BACKLOG

El Sprint Backlog es otro artefacto de Scrum que se crea durante el Sprint Planning y se compone de los elementos del Product Backlog de la parte superior (lo más prioritario) seleccionados que se consideran necesarios a realizarse para cumplir el Objetivo del Sprint y los Developers consideran factible terminar según su velocidad y capacidad.

product-backlog-sprint-backlog

Para determinar cuántos PBIs incluir en el Sprint Backlog nos basamos en la velocidad de los últimos 3 Sprints de los Developers.

✅ Buenas prácticas

¿Qué es el Product Backlog Refinement?

El Product Backlog Refinement (o refinamiento) es el acto de añadir detalle, estimaciones y orden a los elementos de la lista. Es un proceso continuo en el cual el Product Owner y los Developers colaboran acerca de los detalles de los PBI. Durante el refinamiento, se examinan y revisan sus elementos. El Equipo Scrum decide cómo y cuándo se hace el refinamiento. El tiempo de esta actividad normalmente no debe consumir más del 10% de la capacidad del Sprint en curso. Sin embargo, los elementos de la Lista de Producto pueden actualizarse en cualquier momento por el Product Owner.

product-backlog-refinement

Los elementos que se encuentren en la parte más alta de la lista, y por ende con mayor prioridad, deben estar más detallados que los de abajo. En el refinamiento buscamos descomponer esos elementos en elementos lo más chicos posibles. Esto ayudará a los Developers a tener una mejor estimación de los mismos. El refinamiento ayuda a que los PBI cumplan con el Definition of Ready.

⛔ Antipatrones

No tener reuniones de refinamiento

El no realizar este tipo de reuniones de refinamiento hace que cuando lleguemos al Sprint Planning, los PBIs no estén «Ready» y esto nos puede llevar a que:

  • El PBI de mayor prioridad es más grande que la capacidad de los Developers para un Sprint y recién en la Planning nos tendremos que poner a intentar cortarlo en partes mas chicas lo que hará dicho evento mucho mas largo e ineficiente.
  • A los Developers le falta información relevante para estimar durante la Planning y el Product Owner no la tiene en ese mismo momento sino que necesita validarlo con ciertos Stakeholders. Es mejor detectar estos problemas durante las etapas de refinamiento para poder llegar a la Planning con toda la información clara y entendida por todo el Equipo. Esto ahorrará mucho tiempo de planificación.
  • Encontrar dependencias de los PBIs que no podemos resolver en la misma Planning y por ende tener PBIs bloqueados.

Product Owner ausente

Es importante que el Product Owner participe de los refinamientos, ya que como vimos más arriba es su responsabilidad el contenido y ordenamiento del Product Backlog. Si no esta presente se podrán tomar muy pocas decisiones o decisiones que luego las cambie, lo que implica re-trabajo.

Product Owner estima los PBIs

Quien tiene esta responsabilidad son los Developers.

PBIs que indican el CÓMO

Muchas veces notamos que el Product Owner define reglas dentro de los PBIs (o historias de usuario) indicando a los Developers cómo debe realizarse esa funcionalidad. Acá vale recordar que uno de los valores que tenemos en Scrum es el foco y también se aplica a los roles en Scrum. Cada rol tiene su foco y en este caso el Product Owner es el responsable del QUÉ y los Developers del CÓMO. Si el Product Owner empieza a definir el cómo, los Developers tienen a perder motivación, principalmente por falta de maestría en su trabajo. Otra consecuencia de ésto es que los Developers no generan aprendizaje sobre el feedback del cliente ya que no están comprometidos con la solución porque no fueron ellos quienes tomaron las decisiones de cómo resolver el problema.

Si le dices a la gente a donde ir pero no cómo llegar allí, los resultados te sorprenderán.

General George S. Patton

Conclusiones

Como hemos visto, el Product Backlog es un artefacto clave dentro de Scrum y es la principal herramienta que tiene el Product Owner para maximizar el valor del Producto. Si tenés alguna duda o consulta dejamela en los comentarios.