B de Backlog

En la metodología Scrum el backlog es, o debería ser, una lista de historias de usuario ordenada por prioridad. En otras palabras, un backlog es una lista de deseos que expresan los clientes sobre el producto que estamos desarrollando. Lo que no es, o no debería ser, es una lista de tareas, ni tampoco una colección de ideas interesantes para hacer en un futuro que nunca llega.

No es una lista de tareas porque cuando hablemos de historias de usuario, veremos que estas son la expresión breve de los deseos o necesidades del cliente y que se han de plantear como el inicio de una conversación, no como un final. O sea: la historia de usuario ni es una toma de requisitos, ni define lo que tenemos que hacer. Define la necesidad que tenemos que solventar.

El cliente, en el momento de formular una historia de usuario, no sabe como se va a materializar ese deseo. Es más, es nuestro cliente porque contrata nuestros servicios para construir lo que necesita. Ese es el trabajo del equipo de desarrollo, como veremos.

Según la Guía de Scrum (nov 2020), el Backlog de producto es

El trabajo pendiente del producto es una lista emergente y ordenada de lo que se necesita para mejorar el producto. Es la única fuente de trabajo emprendida por el equipo Scrum.

Y también contempla el Backlog de sprint, que se compone básicamente de las historias de usuario que hemos decidido abordar en un período concreto de tiempo: el famoso sprint.

El Trabajo pendiente de Sprint se compone del objetivo sprint (por qué), el conjunto de elementos de trabajo pendiente de producto seleccionados para el Sprint (qué), así como un plan accionable para entregar el incremento (cómo).

En cualquier caso, esta lista de historias de usuario debería estar ordenada por valor decreciente. Cuando más arriba en la pila, más prioritaria, pues la función del backlog es responder a la pregunta: ¿qué deberíamos hacer a continuación? Y lo que deberíamos estar haciendo es lo que sea más importante para el cliente.

Hay más cosas en la Guía de Scrum que posiblemente te sorprendan, porque no se ven mucho:

Un backlog por producto, no un backlog por equipo. Lo más probable es que estés trabajando en un entorno en el que existe un backlog del equipo, incluso aunque haya varios equipos desarrollando el mismo producto. Esto genera dependencias, ineficiencias y silos, ya que ninguno de los equipos tendría una visión general. Un ejemplo del resultado es la típica situación de “estamos esperando a que otro equipo tenga…”, “el otro equipo no tiene planeado esto hasta dentro de…”, etc.

El product backlog debería ser único. Cada equipo tendría un sprint backlog propio con la que sería su aportación durante la iteración en curso.

Aunque mucha gente piensa que el backlog es connatural al trabajo ágil en realidad es solo una prescripción de la metodología Scrum. Un equipo Agile podría trabajar sin backlog. La idea puede sonar extraña, pero si tenemos una colaboración estrecha con el cliente, lo más probable es que sea relativamente fácil determinar en qué tendríamos que estar trabajando en este momento y a continuación.

El problema del backlog no es su existencia o no. El problema es usarlo como un contenedor para:

• Cualquier idea sobre el producto, con independencia de si se necesita o no.
• Tareas técnicas que el equipo considera que necesita realizar porque deuda técnica, etc.
• Bugs, porque por alguna razón podemos convivir con ellos hasta que nos parezca procedente abordarlos.
• Posibles opciones para soluciones técnicas que queremos estudiar algún día.

Por lo general, el resultado de usarlo para estos fines es un backlog enorme, que nunca tiene fin y cuyos items envejecen sin que nos demos cuenta, hasta el punto de que en algún momento dejan de ser relevantes.

Una práctica sana con un backlog es eliminar entradas. Así, por ejemplo, si un item no ha entrado en los últimos dos sprints debería descartarse, incluso habiendo sido refinado: si nadie echa de menos esa prestación ¿para qué preocuparse por ella?. Por supuesto, el tope de dos sprints es totalmente arbitrario, podría ser uno solo.

Ya puedo escuchar los gritos de horror: Pero si a lo mejor es una buena idea. Lo que pasa es que hay otras cosas que han sido más importantes y, por tanto, se han priorizado por encima de esa. Pues la respuesta que tengo es: si realmente es algo que aporta valor volverá en algún momento. Esto es algo que los equipos Lean suelen hacer: mantener un backlog muy actualizado, eliminando cualquier cosa que no se haya movido en el último mes.

Steve Jobs decía que para mantener el foco hay que decir no a muchas cosas, pero sobre todo a muchas buenas ideas. La moraleja de esta frase es precisamente que lo importante es identificar lo que tendríamos que estar haciendo ahora mismo. No lo que podríamos llegar a hacer algún día.