Qué es Backlog y qué importancia tiene en el Desarrollo de Proyectos

Este concepto forma parte del método de trabajo Scrum, la cual se refiere a una metodología ágil basada en el desarrollo de proyectos de cualquier tipo mediante el seguimiento de distintas técnicas, fundamentándose en un ciclo de mejora continua. Es un concepto que obligatoriamente deben conocer los profesionales dedicados a la Dirección de Proyectos o que desean obtener el certificado PMP otorgado por el Project Management Institute (PMI).

La palabra Backlog, viene del inglés, y significa “acumulación de algo, especialmente trabajo incompleto o cosas de las que debemos ocuparnos”, es decir, una pila o un montón de trabajo. Por lo general la palabra aparece junto a Producto, debido a que el “Product Backlog” corresponde al artefacto que funciona como contenedor de todo el trabajo que hay que hacer para lograr el desarrollo de un producto, es decir que es una lista de todo el trabajo pendiente, ordenado por prioridad.

En dicha lista incluye todos los requerimientos iniciales del proyecto que se desarrollará, es una lista dinámica que evoluciona a medida que el producto y el entorno del proyecto lo hacen. El objetivo de la lista es identificar las necesidades del producto para alcanzar su mayor utilidad.

El product backlog describe las tareas y subtareas que se van a realizar para ejecutar cada requisito, estimando el tiempo que llevará desarrollar cada tarea y el valor que aporta cada una al producto.

Importancia

El backlog constituye un esquema fiable de los elementos de trabajo de un proyecto que se puede compartir, estos impulsan debates y decisiones que mantienen la salud de un programa. Gracias a esto, las partes interesadas cambian las prioridades, pues al fomentar las conversaciones sobre lo que es relevante, sincroniza las prioridades de todos, creando una cultura de priorización colectiva que asegura que todos compartirán la misma idea del programa.

Asimismo, el backlog sirve como base para planificar las iteraciones, por ello debes incluir todos los elementos de trabajo, tal como: historias de usuarios, bugs, cambios de diseño, deuda técnica, solicitudes de clientes, elementos de acción de la retrospectiva, entre otros. Para garantizar que incluyes los elementos de trabajo de todos en la conversación general de cada iteración. Incluso, los miembros del equipo pueden negociar con el propietario del producto previo a una iteración, teniendo el conocimiento completo de todo lo que se tiene que hacer.

Características del producto Backlog

El backlog no es una simple lista de tareas, en esta los elementos se integran, y dichas entradas tienen ciertas características:

1. Las entradas del Backlog siempre deben agregar valor para el cliente.
2. Las entradas del Backlog deben estar priorizadas, es decir, ordenadas por criterios de prioridad tal como valor de la funcionalidad para el cliente, tamaño, dificultad, entre otros. Por ende, mientras más relevantes sean, más arriba deben estar.
3. Dependiendo de la posición de cada entrada en la lista, será el nivel de detalle que se le dará, los de más arriba estarán más detallados para poder tratarse antes. Mientras que los de más abajo tendrán menos detalles, ya que se abordarán posteriormente, incluso puede que se modifiquen o se descarten.
4. Todas las entradas deben estimarse.
5. Los backlog son documentos vivos, que pueden sufrir cambios, y del que puede entrar o salir trabajo.
6. No puede contener elementos de acción ni tareas de bajo nivel.

Inicio en el manejo de la herramienta scrum Backlog

Los elementos que hay que tomar en cuenta para iniciar con la herramienta de Scrum Backlog te los detallamos a continuación.

La base del backlog del producto es la hoja de ruta y requisitos de un equipo, las iniciativas de hoja de ruta se dividen en varios epics y cada uno cuenta con varios requisitos e historias de usuario. Posteriormente, el propietario del producto organiza las historias de usuario en una sola lista para el equipo de desarrollo. Así pues, el propietario puede optar por entregar inicialmente un epic completo o puede que sea más importante para el programa elegir algo más económico que tenga historias de distintos epics.

Lo que puede influir en la priorización del propietario del producto, es:

1. Prioridad del cliente.
2. Urgencia de tener feedback.
3. Dificultad relativa de la implementación.
4. Relaciones simbióticas entre elementos de trabajo.

Si bien es cierto que el encargado de priorizar el backlog es el propietario del producto, no es una tarea que se haga de forma aislada, si se es un propietario de producto eficaz buscará comentarios y opiniones de los clientes, diseñadores y equipo de desarrollo, con tal de optimizar la carga de trabajo de todos y la entrega de producto.

Consejos para la realización las entradas

1. Entradas que aporten valor: todas las entradas deben agregar valor al cliente, de lo contrario deberá ser excluida pues será un desperdicio de tiempo y esfuerzo. Pueden incluirse entradas que permitan explorar las necesidades del cliente, analizar opciones técnicas, describir requisitos funcionales y no funcionales, el trabajo necesario para lanzar un producto y otras entradas de trabajo como la corrección de errores (bugs) o la configuración del entorno. Pueden surgir dudas con tareas que no aporten un valor directo a cierta funcionalidad, pero al final, agregarán valor si contribuyen a incrementar la calidad del código o disminuir los errores e incidencias a mediano y largo plazo.
2. Varios niveles de detalle: esto se debe a que no vale la pena invertir tiempo y esfuerzo en describir detalladamente una entrada o tarea hasta que esta no comience su implementación, ya que es muy probable que cuando se vaya a abordar dicho trabajo los requisitos hayan cambiado sustancialmente. De allí que las entradas de Backlog tengan distinta granularidad, los elementos que se vayan a implementar en los próximos sprints deben definirse detalladamente, mientras que los demás pueden estar definidos de forma general.
3. Priorizar: las entradas se deben organizar en base a su prioridad en orden descendente, esto debe hacerlo el product owner, pero puede tener la colaboración del resto del equipo scrum. Los factores que más se tienen en cuenta para priorizar las entradas son: valor que aporta al cliente/negocio, tamaño, coste, dificultad o riesgo. Gracias a esto, entonces el product owner puede saber cuál es el trabajo que se debe hacer a continuación.
4. Estimar todas las entradas: se estiman de acuerdo con la definición acordada, y puede usarse la estimación para priorizar las entradas del backlog y planificar las entradas.
5. Tareas de bajo nivel: no se le asigna información detallada a las funcionalidades o historias de usuario. Es responsabilidad del equipo de Scrum y su lugar el Sprint Backlog, desglozar y distribuir dichas entradas en tareas de mayor detalle que integren los requisitos con mayor grado de refinamiento.

Preguntas frecuentes sobre Backlog

Algunas dudas comunes con respecto al backlog te las respondemos a continuación:

¿Cuál es la diferencia entre Sprint backlog y el producto backlog?

Cuando se habla de sprint backlog, este es creado durante el evento de sprint planning, compuesto por elementos seleccionados de la parte superior del product backlog, es decir los más prioritarios, considerados los más necesarios para poder cumplir el objetivo del sprint y que los developers creen factible terminar de acuerdo con su velocidad y capacidad. Mientras que como ya lo hemos mencionado, el product backlog, corresponde a la lista de todas las tareas necesarias para un proyecto, ordenadas de forma prioritaria.

¿Cuál es la mejor manera de mantener un Backlog?

Cuando el backlog ya está creado, se debe mantener periódicamente para que mantenga el ritmo del programa, son los propietarios del producto los que deben revisar el backlog antes de cada reunión, para así planificar la iteración en función de asegurar que se está dando la priorización correcta y que esté incorporado el feedback de la iteración anterior. Dicha revisión periódica se llama «backlog grooming», «backlog refinement» o ajuste del backlog.

Si el backlog incrementa, entonces los propietarios del producto deberán agruparlo en elementos a corto y largo plazo, siendo los de corto plazo, detallados completamente antes de etiquetarlos como tal. Lo que implica que han diseñado historias de usuarios completas, se acordó la colaboración con diseño y desarrollo, y el equipo de desarrollo ha hecho estimaciones.

Por su parte, los elementos a largo plazo pueden ser abstractos, pero es buena idea tener una estimación aproximada del equipo de desarrollo para así favorecer su priorización, será estimaciones aproximadas que cambiarán cuando el equipo entienda por completo dichos elementos a largo plazo y comiencen a trabajar en ellos. Asimismo, el propietario del producto puede cambiar la prioridad del trabajo en el backlog en cualquier momento por comentarios de los clientes, ajustes de las estimaciones o nuevos requisitos.

Pero se debe ser consciente de que los cambios deben ser mínimos cuando el trabajo ya se esté realizando, puesto que interrumpen el trabajo del equipo de desarrollo y afectan la concentración, ritmo y ánimo. Cuando el backlog sea mayor que la capacidad del equipo a largo plazo, entonces pueden cerrar incidencias que el equipo nunca atenderá, marca dichas incidencias con una resolución específica, tal como “fuera de alcance”, usando el gestor de incidencias del equipo para usarlo con fines de investigación posteriormente.

Debes estar alerta ante los antipatrones que te mencionamos a continuación:

1. El propietario del producto prioriza el backlog al comienzo del proyecto, sin ajustarlo a medida que tiene el feedback de los desarrolladores y partes interesadas.
2. El equipo solo limita los elementos orientados a clientes en el backlog.
3. El backlog lo tienen como un documento almacenado localmente y no lo comparten frecuente, lo que impide que las partes interesadas tengan esta información.

¿Se pueden incluir bug en el listado?

La respuesta es sí, de hecho bugs es uno de los tipos de elementos que un product backlog puede tener, pueden incluirse a medida que se detectan, pero si el sprint no ha terminado, y la historia de usuario está en desarrollo, entonces, no es necesario crear una actividad nueva para dar solución al problema, a menos que implique varios cambios.

¿Es mejor el utilizar Backlog en inglés o con traducciones?

No es recomendable usar la palabra backlog en español ya que en español no se tiene una sola palabra que represente eso mismo, alguna de las traducciones que se suelen encontrar son:

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

Estos son términos amplios que en español no son fáciles de ajustar. Por eso, para evitar estas complicaciones, donde se tendría que llamar backlog de distintas formas en cada situación, entonces es mejor usarlo en ingles simplemente.

¿El director del proyecto es el encargado de Backlog?

Esto depende, el director o gerente del proyecto se encarga de gestionar el alcance de proyecto y por ende, está a cargo de gestionar proyectos predictivos, la estructura de desglose del alcance, entonces puede encargarse del backlog. Sin embargo, en proyectos ágiles donde el backlog sirve como instrumento de gestión del alcance, el director del proyecto no aparece como un rol preponderante.

No obstante, se debe hacer una separación entre gestionar el alcance, que corresponde a enfocarse en ofrecer valor de negocio, y gestionar el equipo. Además, esta separación de responsabilidades evita que sean ignoradas las necesidades del equipo y su desempeño, con tal de alcanzar y lograr el valor para el negocio.

Por su parte, aunque no está explícitamente asignado, es común encontrar directores de proyecto a cargo de gestionar el alcance, haciendo el papel de product owners, que a su vez gestionan o dirigen el equipo, esto es similar al papel del scrum master. Debes recordar que el backlog es un instrumento dinámico que necesita más compromiso y dedicación, si eres director de proyectos y hacerte cargo del alcance, no tengas dudas de sumar a tu equipo un scrum master que facilite y medie la relación que tienes con el equipo.

¿Qué se debe evitar al utilizar backlog?

Para evitar que uses mal el backlog y que pierda su efectividad en el proyecto o con un equipo, esto es lo que debes evitar:

1. Acumulación excesiva: no incluyas de todo en el backlog, si bien es un instrumento flexible, no puede ser un baúl de recuerdos o cuarto de almacenamiento, en algunos casos, lo convierten en una lista de deseos interminables.
2. Necesidad de información detallada: no pierdas el equilibrio entre anticipación y adaptación, es necesario una lista inicial priorizada para que puedas trabajar, que permita saber en qué se debe enfocar el guardián. No quieras anticipar todo, pues el backlog está diseñado para contextos complejos adaptativos, donde parte del trabajo incluye la experimentación y realimentación.
3. Estructura monolítica: los elementos del backlog no pueden depender unos de otros, esto es complicado, y para evitarlo debes desarrollar un pensamiento emprendedor, saber que los grandes logros son el resultado de varios pequeños.

Como ves el backlog es esa lista priorizada que te permitirá alcanzar tus objetivos si la usas de forma adecuada, asesórate con tu equipo y sigue la metodología scrum para que funcione. Esperamos que con toda esta información tengas éxito implementándolo en tu proyecto.