Fundamentos de Scrum Framework: Product Backlog vs Sprint Backlog

Este artículo forma parte de una serie en la que revisamos los fundamentos de Scrum complementados con infografías que los explican. Otros artículos: Sprint, Planificación, Daily, Review, Retrospectiva, Product Owner y Scrum Master, Developers

Autores: Alonso Álvarez y Patricia Parreira. 

Scrum se define oficialmente a través de la Guía, un documento creado y mantenido por los creadores originales del marco, Jeff Sutherland y Ken Schwaber. Cualquier libro sobre el tema contiene muchísimo más texto que esa guía que, además, no ha dejado de reducirse en tamaño y aligerarse en cuanto a prescripciones. 

La Guía contiene los elementos básicos de Scrum: reuniones, responsabilidades y artefactos. Los dos primeros se han tratado ya en varios artículos, ahora es el turno de los artefactos. 

El nombre puede sonar un poco extraño, y desde luego no se corresponde con la definición del diccionario. Para Scrum, los artefactos representan el valor o el trabajo por medio de la transparencia, uno de los pilares de Scrum.  

Los tres artefactos son: 

• Product Backlog (o pila de producto)
• Sprint Backlog (o pila del sprint o iteración)
• Product Increment (o Incremento de Producto)

Cada uno de los tres artefactos tiene además un compromiso que ayuda a medir el progreso:  

• El objetivo del producto para el Product Backlog
• El objetivo del Sprint para el Sprint Backlog
• Y la Definition of Done (o Definición de Hecho) para el incremento

Aquí veremos los dos primeros. 

¿Qué es un Backlog?

Un backlog o pila es una lista ordenada, generalmente de trabajos, requisitos, acciones pendientes, tareas, etc.

El hecho de ser una lista implica que hay un elemento detrás de otro, lo que quiere decir que se hacen en secuencia, no todos a la vez. El orden puede ser el que consideremos oportuno en cada momento. Al hablar de trabajos, lo habitual es que ese orden sea la prioridad (en lugar de alfabético, por antigüedad…), donde “prioridad” puede significar varias cosas: desde valor, a urgencia, pasando por esfuerzo, riesgo y combinaciones de esos factores y otros adicionales. 

El modelo de backlog, frente a otros más convencionales como los documentos de requisitos, ofrece también flexibilidad. Es fácil cambiar el orden en el que están los trabajos si consideramos que uno debe realizarse antes que otros. 

Hay varios criterios para determinar si un backlog tiene las características adecuadas. Uno habitual y fácil de recordar y aplicar es DEEP, creado por Roman Pichler y Mike Cohn.

Son unas siglas que significan: 

D de suficientemente Detallado (Detailed appropriately).

Lo que quiere decir que el nivel de detalle no es el mismo en todo el backlog, de forma que los elementos en su parte “superior”, los que están más cercanos a su realización, tienen un detalle mayor; los intermedios, que se podrían llevar a cabo a medio plazo, tienen menos detalle; y los que están en la parte inferior, que haremos dentro de más o tiempo o que quizá ni se lleven a cabo, tiene poco detalle. 

Esta es una forma de asegurar que sólo se invierte esfuerzo de refinamiento en aquello que se va a llevar a cabo con mayor seguridad y dentro de menos tiempo. 

E de Estimado (Estimated).

Lo que quiere decir que hay al menos una primera aproximación del esfuerzo necesario para llevar a cabo cada elemento en una unidad estandarizada y homogénea (para facilitar la comparación). Si aplicamos el criterio anterior, el nivel de precisión esperado será mayor en los elementos de la cabeza de la pila, frente a los que estén por debajo. 

E de Emergente (Emergent).

Esta característica se refiere a que un backlog es dinámico, de forma que puede aceptar nuevos elementos, o eliminarlos, o adaptarlos, o cambiar su orden. 

P de Priorizado (Prioritized).

Como decíamos antes, un backlog es una lista ordenada, y ese orden debe marcar la prioridad de los elementos, de forma que los más prioritarios estén en la parte superior, porque son los que deberían acometerse antes. Esa prioridad puede estar marcada por distintos criterios dependiendo de las necesidades de quienes gestionen el backlog, a condiciones que se apliquen homogéneamente en todo el backlog. 

Product Backlog vs Sprint Backlog ¿Cuáles son las diferencias?

Product Backlog

Scrum define el uso de dos tipos de backlogs. El primero es el de producto, una “lista emergente y ordenada” que es la fuente del trabajo del equipo y recoge las necesidades y mejoras del producto, en el que esté trabajando el equipo. 

El Product Backlog se empieza a construir antes del primer Sprint (es algo necesario para empezar a planificar) y va a permanecer “en obras” hasta que el producto se considere completo (normalmente nunca), o deje de tener sentido, interés o aportar valor. 

Es decir, el contenido de este Product Backlog está sometido a un proceso continuo de refinamiento. Aunque hay equipos que hacen reuniones o procesos formalizados de refinamiento, la Guía deja mucha libertad y sólo habla de “actividades de refinamiento”. Se trata de trabajo para revisar el contenido del Backlog, para descomponer elementos en otros más pequeños (y reducir así el riesgo), para agregar detalles, para revisar el orden prioridad con el que se llevarán a la práctica esos elementos. 

Uno de esos detalles, y no menor, es el tamaño, lo que se puede traducir en el coste, esfuerzo, complejidad, o la escala que considere el equipo. Ese tamaño es estimado, ya que normalmente nos moveremos en un entorno de incertidumbre y novedad, que es donde Scrum es más eficaz. Pues bien, evaluar ese tamaño estimado es responsabilidad de las personas que van a construir el producto en primera persona, los Developers. A fin de cuentas, quien hace un trabajo está siempre en mejor disposición para intuir cuánto supone hacerlo. 

El Product Backlog se define en torno a un compromiso: el Objetivo del Producto (Product Goal).

Esta definición debe existir para explicar lo que busca el equipo con su trabajo, y proporciona una forma de alinear esfuerzos hacia una meta común. Ese Objetivo forma parte del Backlog y todos los elementos que define el trabajo que queda por hacer, nacen de determinar qué es lo que permitirá cumplir ese objetivo. 

El Product Backlog refinado es la entrada del evento de Planificación. Una de sus salidas es el siguiente artefacto.

Sprint Backlog

Recordemos lo que decíamos de la Planificación: su resultado es el Objetivo del Sprint, el trabajo pendiente, y un plan. Es decir: “por qué”, “qué” y “cómo”. Ese “qué”, el trabajo pendiente, es el contenido del Sprint Backlog. 

Se trata de un subconjunto del Product Backlog acordado por todo el equipo y que define el alcance de lo que se quiere conseguir durante el Sprint. Pero no es una vista estática, si no que va evolucionando a medida que el equipo aprende más cosas durante el Sprint. 

Es una herramienta básica de Transparencia que favorece la Inspección y Adaptación, ya que cada día se revisa durante la Daily o reunión diaria, aunque se puede actualizar cuando sea necesario en cualquier momento. Precisamente, para fomentar esa transparencia, muchos de los equipos utilizan herramientas como tableros para reflejar y actualizar el estado del Sprint Backlog.  

El Sprint Backlog es una herramienta de planificación en manos de los desarrolladores, que lo gestionan, aunque puedan apoyarse para ello en la labor de coaching del Scrum Master. Normalmente podemos esperar que su contenido sean las tareas que aportan valor al producto durante el Sprint, y cualquier otra actividad necesaria para llevarlas a cabo y que ayude al equipo a sacar adelante el trabajo. Por ejemplo, el Sprint Backlog es un lugar adecuado para hacer aflorar y seguir la resolución de impedimentos y bloqueos, lo que es también parte del trabajo. 

De la misma forma que el Product Backlog tiene un compromiso para alinear los trabajos, características, necesidades… que van a formar parte del Producto, el Sprint Backlog tiene su propio compromiso: el Objetivo del Sprint. Se crea durante la Planificación y sirve para alinear los trabajos realizados durante el Sprint en un sentido determinado. 

Estos dos artefactos tienen un papel fundamental, y son unas herramientas básicas a la hora de entregar valor a través del último de los tres artefactos, el Incremento o Incremento de Producto, que veremos en un próximo artículo. 

Descargar Infografía completa

¿Quieres conocer más prácticas Scrum?

Te recomendamos la formación “Agile Fundamentals”, un curso de 24h para empezar a aprender los conocimiento y habilidades de Scrum y Kanban, acreditado por ICAgile.

IR AL CURSO Agile fundamentals