Definición de PRODUCT BACKLOG

El Product Backlog (o Lista de Producto) es una lista 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 durante todo el proyecto, 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.

Ejemplo de un Product Backlog

 

¿Como 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 ésto, 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 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 al Equipo de Desarrollo 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. El Equipo de Desarrollo debe 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 el Equipo de Desarrollo 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 Done?

El Definition of Done «DoD» (o definición de terminado) es un acuerdo común que nos sirve para determinar cuándo un elemento de la lista del producto está finalizado. Este mismo acuerdo guía al Equipo de Desarrollo durante la Sprint Planning para saber cuántos ítems podrán completar durante el Sprint.

Usualmente un equipo Scrum al comienzo del proyecto define un Definition of Done básico, por ejemplo, que cumpla con los criterios de aceptación establecidos por el Product Owner. A medida que el equipo madura a este acuerdo se expandirá para incluir criterios más estrictos, lo que llevará a aumentar la calidad del producto.

Si bien en la mayoría de los casos este acuerdo se aplica a todos los elementos de la lista podríamos identificar elementos que requieran tener su propia definición. Por ejemplo podríamos tener un DoD para todos los elementos que sean de nuevas funcionalidades y otro DoD solamente que se aplique a los requerimientos de documentación legal.

Quien es responsable de su definición es el Equipo de Desarrollo. Cuando hay muchos Equipos de Desarrollo trabajando sobre un mismo producto, deberán establecerlo en conjunto.

¿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 el Equipo de Desarrollo no comprende 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».

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

El Equipo de Desarrollo es el responsable 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.

¿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 del Equipo de Desarrollo 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 el Equipo de Desarrollo considera 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 del Equipo de Desarrollo.

✅ 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 el Equipo de Desarrollo 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á al Equipo de Desarrollo 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 del Equipo de Desarrollo 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.
  • Al Equipo de Desarrollo 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 es el Equipo de Desarrollo.

PBIs que indican el CÓMO

Muchas veces notamos que el Product Owner define reglas dentro de los PBIs (o historias de usuario) indicando al Equipo de Desarrollo 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 el Equipo de Desarrollo del CÓMO. Si el Product Owner empieza a definir el cómo, el equipo de desarrollo tiende a perder motivación, principalmente por falta de maestría en su trabajo. Otra consecuencia de ésto es que el Equipo de Desarrollo no genera 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