Las consecuencias de un Backlog interminable

Nuestro Product Backlog con el tiempo se va llenando y convirtiendo en un Backlog interminable. En este artículo te planteo las consecuencias más relevantes que tiene.

El mantenimiento del Product Backlog, o de un Backlog de Portfolio si estamos aplicando algún marco de escalado Agile, es uno de los aspectos más relevantes cuando llevamos tiempo trabajando con Scrum. En muchos casos, casi sin dar nos cuenta, el Backlog estará lleno de elementos que se han quedado obsoletos, que han perdido su relevancia, o que ya no son necesarios. Y sin embargo, nos cuesta eliminarlos con el argumento “para cuando tengamos tiempo”. Eso no va a ocurrir, no vas a tener tiempo, sobre todo si tus equipos Scrum mantienen diferentes productos.

En equipos Scrum que están dedicados en exclusiva a productos o proyectos nuevos, que cubren una necesidad y tienen un tiempo limitado, es más sencillo evitar que el Backlog se llene de elementos innecesarios. Utilizando técnicas de división y priorización temprana, como User Story Mapping, MoSCoW, o Kano, nuestro Backlog estará siempre ocupado con los elementos más importantes para nuestros clientes, y evitaremos que se llene con aquellos que no van a ocurrir.

En equipos Scrum que además de nuevo producto, se dedican a evolucionar y mantener los productos existentes, es mucho más probable que se nos vaya llenando el Backlog de elementos innecesarios. En uno de nuestros clientes anallizando las causas que nos han llevado a una situación de Backlog de Portfolio eterno, llegamos a las siguientes:

W

La creación del Backlog la realizamos partiendo de todas las solicitudes realizadas por las áreas de negocio de la empresa.

W

Incorporamos al Backlog todas las solicitudes de mejora encubiertas enviadas por las áreas de negocio. Es decir, incidencias reportadas que en realidad eran evoluciones o mejoras de los productos.

W

El proceso de llegada de las nuevas solicitudes no tiene criterios de aceptación o rechazo de las mismas. Simplemente se aceptan y se priorizan.

Esto les ha llevado a que su Backlog de Portfolio tenga una profundidad excesiva, y contenga elementos para sus equipos Scrum trabajen durante 3 años sólo para completarlo, sin que entre nada nuevo. Si estás leyendo esto, es muy probable que te sientas identificado.

Consecuencias de un Backlog Eterno

En próximos artículos te contaré formas simples de mantener el Backlog controlado, pero hoy lo que quiero es que entiendas las consecuencias que detectamos en nuestro cliente, por tener un Backlog eterno.

\

Sensación de "Nunca vamos a acabar"

Es algo que nos pasa a todos cuando tenemos una lista de tareas tan larga, que no le vemos el final. Da igual el tiempo que dediquemos, no se va a acabar. En los equipos Scrum ocurre lo mismo. Con Backlogs tan grandes, es muy fácil que se instale la sensación de que no importa cuánto entreguen, ni su velocidad, ni lo que mejoren sus procesos o como equipo, simplemente hay tanto trabajo que no se va a acabar nunca. Y esto puede llevarles a la desmotivación, el desánimo, la relajación, el síndrome del quemado, y muchos otros estados de ánimo que van a frenarles en su evolución como equipo Scrum y en el aporte de valor a la empresa.

\

Un mayor esfuerzo para mantenerlo

El esfuerzo necesario para mantener el Backlog priorizado, ordenado y con la información actualizada aumenta exponencialmente con el número de elementos que contiene.
Cuántos más elementos más matices hay a la hora de priorizar. El aporte de valor será muy similar a más elementos, y necesitaremos disponer de una información con un mayor nivel de detalle para poder decidir.
Cuánto mayor nivel de detalle de la información sea necesario para decidir, más tiempo tienen que dedicar los Product Owner a conseguir la información y mantenerla actualizada. Y esto de una cantidad excesiva de elementos.

\

Duración sesiones de trabajo con el Backlog

Especialmente las sesiones que tenemos con las áreas de negocio para priorizar el Backlog de Portfolio. Es algo fácilmente entendible, priorizar 10 elementos es mucho más rápido y sencillo que priorizar 50. Y lo mismo ocurre con las sesiones propias de los equipos Scrum, o de coordinación de los Product Owners.
Aquí también entra en juego la cantidad de información que necesitamos para decidir.

\

Y lo mío para cuándo

Las áreas de negocio entienden que todo lo que está en el Backlog se ha aceptado, y por tanto, comprometido su desarrollo. Pero cuando ven la cantidad de elementos que hay, y cuántos están por delante de su solicitud, cunde el desánimo y desconectan de las sesiones de coordinación de IT con negocio. O simplemente dejan de asistir.
Además es muy complicado gestionar sus expectativas. No importa cuánto mejore su velocidad de entrega de valor el área de IT, siempre tendrá un montón de solicitudes sin atender, y por tanto, áreas de negocio descontentas.

Resumen

La dinámica del día a día y el afán de atender todo aquello que te solicitan, tendrá como consecuencia un Backlog eterno, que provocará a nivel general en nuestros equipos Scrum y en la empresa, la sensación de “esto no va a acabarse o hacerse nunca”. Recuerda que una de las mejores armas de un buen Product Owner es saber decir “No ahora, sí más adelante”.

En nuestro artículo ¿Como evitar un Backlog eterno?, te contamos algunos trucos para no llegar a esta situación.

También te puede interesar.

El uso de las Métricas para saber nuestro nivel de Incertidumbre

Scrum nos ayuda a manejar la incertidumbre. Pero ¿cómo sabemos que lo estamos consiguiendo? ¿Qué métricas pueden ayudarnos a confirmar que tenemos bajo control la incertidumbre?

Como empezar como Scrum Master

Acompañar a equipos es una gran responsabilidad pero es muy gratificante. Cada persona y cada equipo tiene unas necesidades diferentes en función de su realidad. Sin embargo, bajo nuestra experiencia, estos consejos pueden servirte para iniciarte como Scrum Master en un equipo.

Scrum para disipar incertidumbre

Scrum es un marco que te puede servir para hacer lo mismo de siempre a trocitos. Sin embargo, puedes utilizar Scrum de manera inteligente y sacarle toda su potencia. ¿Cómo? Orientándolo a generar certezas sobre tu producto o tu mercado.

Cómo facilito una retrospectiva si no soy Scrum Master

Una buena retrospectiva da la oportunidad al equipo de analizar su funcionamiento y establecer mejoras. Te dejamos consejos para facilitarla.

Sprint Review: más allá de la demo

La Sprint Review es el evento de Scrum donde se muestra el resultado del sprint. Una buena review te ayudará en la estrategia de producto.

La historia de scrum, su primera implementación

Actualmente Scrum es el marco de trabajo más utilizado para implementar modelos Agile. Hoy os contamos como era su primera versión.

Informar a la dirección con el Burn Up

El uso de Agile junto con Scrum u otros métodos, no elimina la necesidad de visualizar la que está ocurriendo a las capas superiores, a los clientes internos, e incluso a la dirección. El Burn Up es una herramienta sencilla que nos ayudará en esta tarea.

Plan para formar a Scrum Master propios de la empresa

En todo acompañamiento en la transformación a la agilidad con Scrum, llega un momento en que los Agile Coach y Scrum Master externos a la empresa deben dejar al Cliente que siga su camino. Y con garantías de que no se va a perder lo conseguido y se va a seguir fomentando la mejora continua y el customer centric.

Sube el nivel de los Scrum Master

Es importante cuidar el rol de Scrum Master ya que es el encargado de velar por la transformación del equipo y la organización.

¿Tiene mi equipo Scrum los conocimientos necesarios para construir mi Producto?

Scrum propone que nuestros equipos tengan todos los conocimientos para generar productos que cubran nuestras necesidades. Te traigo hoy una herramienta sencilla para averiguar si tus equipos Scrum son realmente multidisciplinares.

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada.

Aceptarás nuestra política de cookies si continúas navegando.

ACEPTAR
Aviso de cookies