¿Qué es un Backlog y cómo se usa en los proyectos y el desarrollo de productos?

¡Comparte!

Empecemos sin rodeos, ¿qué es el backlog? Es una herramienta para la gestión de requerimientos / requisitos sobre un producto, servicio o proyecto. Parafraseando el Scrum Guide, que de paso sea dicho, fue actualizado en noviembre de 2020, es una lista abierta y ordenada de solicitudes para mejorar o completar el valor de algo – ya sean productos, servicios o proyectos.

El backlog, una lista priorizada de requerimientos sobre un producto o servicio, es un mecanismo de desglose ideal para la gestión de requerimientos cuando éstos son variables y muy dinámicos. A diferencia de otros mecanismos de desglose, como la estructura de desglose del proyecto EDT o WBS por sus siglas en inglés, éste tiene varias particularidades que comentaremos más adelante y que son clave en su éxito en la gestión de proyectos adaptativos y el desarrollo de productos y servicios.

¿Qué elementos van dentro del Backlog?

El backlog es una lista abierta de elementos. Puede tener requerimientos específicos para un proyecto o producto, puede incluir tareas, puede incluir casos de uso o historias de usuario, y lo más importante, puede contener una combinación de todas ellas.

El backlog solo puede contener historias de usuario

¡FALSO, FALSO, ABSOLUTAMENTE FALSO!

Esto es algo que como consultor y agente de cambio veo todo el tiempo. Equipos sufriendo, intentando documentar todos y cada uno de sus requerimientos y elementos del backlog como historias de usuario. ¡Es una tremenda estupidez!

Cada forma de escribir un requerimiento es particular a la naturaleza del producto o servicio en desarrollo. Algunos «tipos» de requerimientos promueven el desarrollo autónomo y otros, en cambio, son más detallados y están orientados al cumplimiento estricto de algunas condiciones.

La madurez del equipo también es un factor importante para considerar que tan detallado y profundo es la información que acompaña los elementos de esta lista priorizada.

¿Por qué Backlog en inglés y no usar traducciones?

Personalmente, no me gusta traducir la palabra backlog, porque en español no tenemos una sola palabra que represente lo mismo. Hace algunos años, cuando era voluntario en el grupo de traducción de la Guía de Práctica Ágil del PMI, fue una de las discusiones más difíciles, así que acá les dejo algunas de las traducciones más populares en el contexto de proyectos y agilidad:

1. Pila
2. Lista priorizada
3. Lista emergente y ordenada
4. Lista de trabajo pendiente

Como ven, son términos amplios que, en español son difíciles de ajustar, y solo para terminar, les dejo un ejemplo de por qué es tan complejo traducir la palabra.

Sprint burndown chart is a visual representation of the sprint backlog remaining work through the days.

Sería algo como:

El diagrama de quemado de la iteración es una representación visual del trabajo pendiente de la lista priorizada de trabajo pendiente de la misma iteración a lo largo de los días.

Para evitar estas cosas, tendríamos que llamar el backlog de diferentes maneras en cada situación. Lista, lista priorizada, pila y no habría forma, para alguien que está aprendiendo, entender que a veces la lista, la lista priorizada y la lista de requerimientos – o como lo traduzca en el contexto – son el mismo instrumento.

Como ven, no es un término simple de traducir, y mucho menos si usan palabras tan fuera de contexto como pila – stack ^[1] Admito que algunas traducciones dentro del contexto de gestión y agilidad backlog a pila, scheduling a programación, feedback como realimentación, burndown chart a diagrama de quemado, y burnup chart como diagrama de quemado hacia arriba, me generan un profundo escozor. .

¿Qué tipos de listas priorizadas existen?

Antes de empezar quiero aclarar que, aunque Scrum está de moda por estos días, el backlog no es un instrumento exclusivo de Scrum. Por ejemplo, XP definió muy bien el backlog hace ya algunas décadas. Asi que, empecemos:

1. Backlog de Producto o Servicio – Product Backlog

Cuando hablamos de Backlog de Producto o Servicio nos referimos a todas las solicitudes asociadas al desarrollo, mantenimiento u operación de un producto o servicio. El backlog de producto incluye, entre otras, tareas, requerimientos asociados a entregables, mejoras, solicitudes de cambio, mantenimientos, y todo aquello digno de mantener «en el radar» para determinado producto o servicio.

2. Backlog de Proyecto

El Backlog de un proyecto es útil en algunos contextos específicos y no es un reemplazo absoluto para otras herramientas de desglose como la Estructura de Desglose del Trabajo (EDT o WBS en inglés). En un proyecto de alcance variable, el uso del backlog es más eficiente y práctico que el uso de la EDT.

¿EDT/WBS o Backlog para gestionar el desglose?

Esta puede ser una discusión profunda y extensa, pero acá va una lista de 3 diferencias CLAVE para elegir entre una EDT o un backlog como herramienta para el desglose.

1. Naturaleza del alcance del proyecto. Si el proyecto es de alcance cerrado y parte del trabajo de la gestión es mantener en cintura las solicitudes adicionales, la EDT es la correcta. Si, por el contrario, parte del proyecto es descubrir, madurar o afinar el alcance del producto o servicio en desarrollo, entonces el backlog es imbatible.
2. No todo está incluido. Una de las cosas más difíciles de comprender para un gerente de proyecto es el hecho de que, los elementos del backlog no están necesariamente comprometidos para entrega. Esto es lo opuesto a la EDT. Todo, y solo aquello, que está dentro de la EDT es parte del alcance. En una EDT, lo adicional se considera gold plating. El backlog, es un instrumento que ofrece prioridades u orden y, por lo tanto, cambios o descubrimientos naturales al proceso de desarrollo del producto o servicio, pueden desplazar a otras características o solicitudes que, a la luz de los nuevos hallazgos no tienen la misma prioridad.
3. Más allá del proyecto, la operación. La EDT es un instrumento cerrado que procura contener todo el alcance, y por lo tanto no es útil en entornos donde no hay un alcance definido. ¿Cómo podríamos gestionar un conjunto de solicitudes inesperadas o no-anticipables para un equipo? La EDT no está diseñada como un instrumento dinámico y flexible, y aunque puede recibir cambios y actualizaciones a lo largo de un proyecto, no es un «elemento dinámico», como si lo es un backlog.

3. Backlog de Iteración – Iteration Backlog ó Sprint Backlog en Scrum

El Backlog de Iteración hace referencia a un conjunto de cosas por hacer o completar en un periodo de tiempo. Si hablamos de Scrum, versión 2020, el Sprint tiene una duración entre una semana y un mes. Si hablamos de Scrum, versiones anteriores o de otros autores, entre dos y ocho semanas. Pero en general, el Backlog de Iteración es la lista priorizada de «cosas por hacer» durante un periodo de tiempo fijo.

El Backlog de Iteración no es, necesariamente, un subconjunto del Backlog del Producto el Backlog del Proyecto. Desde luego, debería existir una relación entre ambos, cuando se usan, pero parte del proceso de planificación de la iteración es detallar, desglosar y completar el backlog de producto/proyecto para la iteración que empieza. Y, en este sentido, es posible que el Backlog de Iteración tenga elementos que no fueron incluidos en el Backlog de Producto o Proyecto.

4. Backlog de Portafolio

Considere por un momento que su portafolio estratégico – que contempla varios proyectos y otros componentes – es una lista priorizada. ¿Por qué no usar el backlog a nivel del portafolio? Priorizar es una excelente idea para evitar lo que he definido como el síndrome del glotón – o considerar que el dinero es el único factor para considerar al incluir o eliminar una iniciativa del portafolio.

En la gestión Lean del Portafolio, el Backlog del Portafolio es un instrumento fundamental. También aparece en el Scaled Agile Framework.

5. Backlog de Programa

Cuando gestionamos productos o proyectos complejos, es posible tener una categorización del backlog. Similar a lo que ocurre con un programa y un proyecto, el backlog puede ser un instrumento valioso para gestionar el trabajo pendiente y las prioridades a gran escala, entre múltiples equipos – claro, cuando la escala lo amerita, es decir, cuando somos tantas personas interactuando que mantener todo centralizado ayuda y entorpece a la vez.

6. Backlog de Equipo

Si existe un backlog de programa, entonces debe existir un backlog de equipo. Si, para efectos de la visión general, unificamos nuestra «pila», para efectos de gestión de un equipo – casi siempre ágil – necesitamos una versión reducida y enfocada para gestionar. Este es lo que se conoce como backlog de equipo.

¿Cómo se gestiona correctamente una lista priorizada?

El backlog, como ya hemos visto, es un instrumento relacionado con el trabajo por hacer, ya sea este asociado al alcance del producto o servicio, o a tareas asociadas a su desarrollo, mantenimiento y operación. Por lo tanto, el backlog requiere mucho trabajo y esfuerzo para mantenerse al día y no perder valor.

En algunos modelos de gestión, se asigna a una persona como el «guardián» o encargado del backlog. En Scrum, este rol se conoce como el Dueño del Producto o Product Owner. No obstante, y dado que el backlog como artefacto no es exclusivo de Scrum, encontramos roles asociados al cuidado y mantenimiento del backlog.

Roles a cargo de crear y gestionar los elementos de la lista priorizada

Aunque esta no es una lista exhaustiva de roles, son los más populares o comunes.

• Gerente del Producto / Product Manager
• Dueño del Producto / Product Owner
• Cliente / Customer
• Representante del Cliente o Consumidor / Customer Proxy
• Analista de Requerimientos / Business Analyst
• Documentador
• Director del Proyecto* / Project Manager

¿Está el director de proyecto a cargo del backlog?

Depende. El director o gerente del proyecto está a cargo de gestionar el alcance de proyecto y, por lo tanto, si está a cargo de gestionar, en proyectos predictivos, la estructura de desglose del alcance, ¿por qué no estaría a cargo del backlog?

No obstante, en los proyectos ágiles, donde el backlog se luce como instrumento de gestión del alcance, el director del proyecto no aparece como un rol preponderante. Por ejemplo, en el modelo de gestión de equipos Scrum existen los roles Scrum Master y Product Owner. Ésta es una clara separación entre gestionar el alcance, es decir, enfocarse en ofrecer valor de negocio y, gestionar el equipo. De esta manera, se ofrece un equilibrio entre el querer hacer y el poder hacer. Así mismo, esta separación de responsabilidades evita que se ignoren las necesidades del equipo y su desempeño con tal de perseguir y obtener el valor para el negocio.

Aunque no está explícitamente asignado, si es común encontrar directores de proyecto a cargo de gestionar el alcance – como Product Owners – y que gestionan o dirigen el equipo – de forma similar a lo que podría entenderse como el rol del Scrum Master ^[2]Siempre se discute a fondo si director proyecto puede ejercer el rol de Scrum Master. En la realidad sucede con frecuencia, En lo personal considero que son roles complementarios y que, con las habilidades correctas, pueden ser ejercidos por la misma persona.

Consejo para los directores de proyecto.

El backlog es un instrumento dinámico que, a diferencia de la EDT, requiere mucho más compromiso y dedicación. Si disfrutas como director de proyectos, hacerte cargo del alcance, no dudes en sumar al equipo a un Scrum Master que facilite y medie la relación que tienes con el equipo. Evita ser juez y parte.

¿Por qué cambian los requerimientos?

El backlog es un instrumento dinámico y abierto. Esto quiere decir que los elementos dentro del backlog entran, salen y se priorizan con regularidad. Claro está, con ciertos criterios y estructura – que depende del modelo de gestión o paradigma que estés usando en tu proyecto o con tu equipo.

En consecuencia, el backlog es ideal en entornos donde, por ejemplo, la realimentación – feedback – es crítica para definir el futuro del proyecto (o el producto). Un ejemplo de este contexto es el emprendimiento. Los emprendedores necesitan de nuevos clientes y, para conocerlos, exponen rápidamente y de forma frecuente, sus ideas en nuevos productos, servicios y campañas publicitarias. Si la respuesta es positiva, profundizan en dicha idea, si la respuesta es negativa, «pivotean» y continúan.

El backlog acepta y potencia la realimentación o feedback. Un buen equipo aprovecha la realimentación para mejorar las capacidades de un producto o servicio en desarrollo.

Refinamiento y cómo mantener el backlog al día

Recordemos que el backlog es un instrumento valioso en contextos donde el alcance del producto, servicio o proyecto requieren cierto dinamismo. Gestionar el backlog es una tarea demandante y muy necesaria para el éxito del proyecto. No se trata sólo de identificar lo que hay que hacer, si no estructurar, priorizar y ordenar el trabajo para lograr el mayor impacto.

Una de las actividades que más peso ha tomado en los últimos años es lo que antes conocíamos como Backlog Grooming y, por razones obvias hoy se conoce como Backlog Refinement^[3]El diccionario Cambridge presenta entre sus definiciones de la palabra grooming, una que ha ganado terreno con los años y se asociada a una actividad criminal. Esto derivó en una modificación del término dentro de la Guía de Scrum de grooming a refinement. .

En el marco de Agilidad a Escala SAFe, el refinamiento del backlog se define más o menos así: ^[4]La traducción del refinamiento del backlog no es literal y se ajusta un poco al contexto de este artículo – sin cambiar su esencia. Para ver el texto original lo invito a navegar la página de Scaled Agile Framework.

El backlog debe siempre contener algunas historias listas para su implementación. Es decir, sin grandes riesgos, profundas incertidumbres o sorpresas importantes. Los equipos ágiles, al adoptar un enfoque basado en el flujo, procuran mantener cierto nivel de «alistamiento» en su backlog. Esto lo logran, al realizar al menos una sesión de refinamiento del backlog por iteración o incluso por semana. Durante esta sesión de refinamiento, se analizan historias de mayor prioridad y se discute, estima y establece un entendimiento inicial de los criterios de aceptación.

Scaled Agile

Consejos para mantener un buen backlog

Quisiera tener una fórmula mágica para compartir sobre cómo gestionar y mantener un backlog bueno. Seguramente sería millonario, pero no por eso no podemos dejar algunos buenos consejos para mejorar las probabilidades de contar con un buen backlog en nuestros proyectos o con nuestros equipos.

1. Dedicación y compromiso

A diferencia de los proyectos predictivos, la naturaleza variable y dinámica del alcance, requiere dedicación y compromiso con el backlog. En Scrum, por ejemplo, el rol de Product Owner es de dedicación exclusiva. Gestionar el backlog requiere tiempo. Olvide la idea de revisar el backlog de cuando en vez.

Dele prioridad y poder a la persona guardiana del backlog. Todos los miembros del equipo, e incluso los stakeholders, son bienvenidos a proponer nuevos elementos, cambios y nuevas prioridades para el backlog, pero solo una persona debe ser quien, en últimas, acepta, profundiza y prioriza el backlog – por eso me gusta la palabra guardián. Si está haciendo Scrum, no dude en asignar su mejor Product Owner disponible a tiempo completo.

2. Pensamiento incremental para los elementos

El backlog no es solo una lista priorizada. ¿De qué nos sirve priorizar si para completar los elementos de primera prioridad necesito completar los elementos de menor prioridad? Este error o antipatrón ágil es común en muchos proyectos que solo se preocupan por fragmentar el plan en iteraciones, pero no profundizan lo suficiente en cómo estructurar las entregas y los componentes para permitir la entrega de beneficios de manera continua. Para evitarlo, se ha definido el criterio INVEST para los elementos del backlog.

Criterio INVEST

El backlog requiere elementos que cumplan el criterio INVEST:

• Independientes (I) – elementos que, en su mayoría sean «autocontenidos» y no requieran de otros elementos para demostrar su valor.
• Negociables (N) – el backlog no es un elemento cerrado y, por lo tanto, algunos elementos del backlog han de ser completados y otros no. Esto significa que, en todo momento, debemos estar en capacidad de negociar las prioridades y la inclusión o no de un elemento en un determinado momento del producto.
• Valiosos (V) – si el backlog es una lista priorizada de elementos, bueno, el valor es lo que nos permite priorizarlo. Aunque puede haber elementos de poco valor en el backlog, mantenerlos allí cuando hemos identificado que son de poco valor, no tiene mucho sentido.
• Estimable (E) – a medida que un elemento del backlog se acerca a la parte alta de la lista priorizada – es decir, está próximo a ser considerado para ser incluido en el proceso de desarrollo o producción – este debe ser estimable. Es decir, el equipo del proyecto o producto debe poder discutir qué tanto esfuerzo, qué tan complejo y qué tan riesgoso es. Para lograrlo, el elemento puede ser detallado – en las sesiones de refinamiento – o fragmentado – en componentes más pequeños que permitan al equipo avanzar.
• Pequeño (Small) – este criterio aplica, más que todo, en los backlogs de Equipo e Iteración. Los elementos fluyen mejor a través del sistema cuando son pequeños – un principio básico de LEAN. No obstante, un backlog de portafolio no necesariamente tiene elementos pequeños.
• Verificable (Testable) – en principio, todo elemento de un backlog, al igual que los elementos de una EDT, deben tener cierto criterio de aceptación y/o validación. De otra forma, cómo podremos saber que algo ha sido realizado y que cumple con los objetivos establecidos.

3. Balance entre anticipación y adaptación

El backlog está priorizado. Hay una razón para eso. Foco en lo más importante y valioso para el producto, el servicio o el proyecto. Si no hay foco, no tiene sentido priorizar. Por lo tanto, debes evitar a toda costa intentar anticipar demasiado al inicio del proyecto, o cuando recién se forma el equipo. Encontrar el balance entre anticipar con diseño previo y adaptar, es fundamental para hacer uso sabio del tiempo de los expertos de negocio y del guardián del backlog – por ejemplo, el tiempo del Product Owner.

4. Criterios de priorización preliminar

Gran parte del problema de priorizar el backlog está en la subjetividad del guardián, o los intereses diversos de todos los interesados – también conocidos en inglés como stakeholders. Una gran técnica puede ser establecer un algoritmo, proceso o mecanismo de priorización ponderada que permita tener en cuenta múltiples dimensiones al momento de priorizar. Scaled Agile Framework, por ejemplo, presenta el WSJF como un ejercicio de priorización para el backlog de portafolio.

Quiero aclarar que establecer criterios de priorización no busca eliminar el factor humano de la priorización, por el contrario, es una herramienta auxiliar que busca potenciar la discusión y el debate alrededor de las prioridades. No siempre podemos escoger los elementos del backlog solo porque la persona que lo solicita tiene una oficina más grande que nosotros. En inglés, se utiliza el término HIPPO o highest paid person in the office para señalar el hecho de que a veces no hay ningún criterio y es solo un capricho de alguien con mejor paga dentro de la compañía.

5. Límites porcentuales y embudos

Bueno, si el backlog es un elemento dinámico, y las sesiones de refinamiento suceden con cierta frecuencia, puede ser una buena idea establecer límites para la cantidad de elementos nuevos a discutir, o mejoras y refactors que hacemos una iteración o consideramos durante nuestras sesiones.

Esto, en ocasiones, puede ayudar a mantener el foco y evitar un exceso de experimentación que, al final, nos deje con muchas cosas para probar y pocas cosas para aportar valor.

De igual forma es posible establecer reglas para salir o «morir» dentro del backlog. Por ejemplo, elementos que no logran nunca subir y siempre son reemplazados por otros elementos «más importantes».

6. Herramienta de gestión

Las herramientas de gestión son útiles y establecen una estructura para incluir, gestionar, actualizar y planificar elementos. Desde los post-its y los tableros acrílicos, hasta herramientas de gestión avanzada en sistemas informáticos.

Lejos de llenar una herramienta con mucha información, mi recomendación es la constancia de mantenerla actualizada, ajustar las prioridades, ingresar los nuevos elementos y descartar aquellos que han sido completados o ya no se consideran dentro del plan – la mayoría de las herramientas hacen de manera automática gran parte de estas tareas.

Cosas que debes evitar

Bueno, al igual que cualquier otra herramienta, el backlog tiene varias consideraciones para evitar que se use mal o pierda efectividad su utilización en un proyecto, o con un equipo. Estos problemas son:

1. Acumulación excesiva. Evita incluir de todo en el backlog. Aunque es un instrumento flexible, tampoco puede convertirse en un baúl de los recuerdos o un cuarto de san alejo. Es común que el backlog se para algunos una lista de deseos interminable.
2. Necesidad de información detallada. Lo mencioné antes, evita perder el balance entre anticipación y adaptación. Necesitas una lista inicial priorizada para poder trabajar, pero las prioridades dictan en qué debe enfocarse el guardián. Evita anticipar todo, el backlog está diseñado para contextos «complejos adaptativos» donde parte de alcance del trabajo contempla experimentación y realimentación – feedback.
3. Estructura monolítica. Evita que los elementos del backlog dependan todos unos de otros. Esto no es tarea simple. Para evitarlo es bueno desarrollar un pensamiento emprendedor, donde los grandes logros son la suma de cada uno de los pequeños logros.

Plantillas para la gestión del backlog

Esta es una necesidad común. ¿Existe una plantilla definitiva para la gestión del backlog? Por supuesto que no. Pero eso no significa que no pueda compartir algunas muy interesantes. Acá una lista de plantillas:

• Backlog Management Tool
  Desarrollado por Sperta Consulting. ^[5]Sperta Consulting es la empresa de la que soy socio. Se especializa en consultoría, acompañamiento y entrenamiento en temas de gestión de equipos y proyectos y estructura organizacional.. Esta es una herramienta que usamos con fines académicos para discutir, sobre todo, el impacto de las iteraciones sobre el progreso de un proyecto. Lejos de ser perfecta, ayuda a establecer discusiones profundas con los ejercicios que realizamos en nuestros cursos.

• Agile Project Plan – Plantilla
  Desarrollado por SmartSheet. Es una herramienta muy completa – y por lo tanto, un poco compleja.

• Plantillas para Iteraciones de 14 y 30 días.
  Desarrollado por Mitch Lacey y Asociados.

Personalmente no uso las plantillas en mi trabajo diario – o es muy muy raro, pero son muy útiles para los procesos académicos. Son fácilmente manipulables y personalizables para exponer un punto, un concepto o beneficios y desventajas.

En nuestro tiempo, es más común utilizar una herramienta de gestión de equipos ágiles en la nube y no un archivo de hoja de cálculo compartido.

Consideraciones finales

El backlog es un instrumento realmente poderoso. Un buen backlog es clave para la agilidad de equipos y el desarrollo incremental de productos y servicios. Es un gran aliado de proyectos ágiles y parte esencial de la gestión lean del portafolio.

No obstante, no debe considerarse solo una lista de cosas por hacer.

¡Comparte!