¿Cómo evitar que el Product Backlog sea eterno?

Un Product Backlog que nunca se termina es una de las preocupaciones de un Product Owner. Un principio básico del Product Backlog es el de la rentabilidad: se mantiene vivo mientras siga siendo rentable invertir en nuevas características de nuestro producto o servicio . En este artículo te voy a explicar  5 sencillos trucos  que utilizamos en nuestros clientes para mantener siempre un Product Backlog realmente rentable y saber cuándo y cómo ponerle fin. Sigue leyendo y evita que el Product Backlog sea eterno.

En mi artículo anterior Consecuencias de un Backlog Eterno te conté qué suele ocurrir en los equipos Scrum y en las áreas de negocio cuando nuestro Backlog es demasiado grande, es casi interminable o eterno. La principal sensación es la de “da igual lo que hagamos, nunca se acaba”, y el desánimo que provoca. Evitarlo puede ser algo sencillo si se establecen procedimientos y utilizamos algunas técnicas al alcance de cualquiera.

El mayor enemigo del Product Backlog es no decir “ahora no”, y dejar que todo entre. Dependiendo de la cultura y dinámicas internas de tu empresa, esto puede ser sencillo, o algo muy arriesgado por las consecuencias que tiene. Lo que buscamos cuando ponemos en marcha esos procedimientos y técnicas, es dar a los Product Owner herramientas y argumentos para decir “ahora no”.

Evitar el Product Backlog eterno

Éstas son algunas de las acciones que hemos puesto en marcha en clientes dónde se detectó que teníamos un Product Backlog eterno. Se pueden aplicar tanto a los Product Backlog de los equipos Scrum, como a un Backlog de Portfolio si estás utilizando algún escalado Agile.

\

Establece criterios de aceptación para incluir elementos en tu Backlog

Establece unos criterios mínimos que debe cumplir cada petición o solicitud que te llegue para que sea incluida en el Backlog. No es necesario que sean muchos o complejos, en realidad con 2 ó 3 será suficiente para evitar que se acumulen en el Backlog elementos innecesarios.

En todos los clientes proponemos siempre que uno de los criterios sea que la petición esté asociada a los objetivos estratégicos de la empresa. Y que esa información venga incluida en la petición. Atiende a principalmente a dos objetivos:

    • Maximizar la entrega de valor de los equipos Scrum.
    • Dedicar nuestra fuerza a lo más relevante para la empresa.
\

Establece un procedimiento de llegada

Establece un procedimiento que determine cómo y a través de qué canales deben llegar las peticiones y así mantener orden. 

El medio para que lleguen las peticiones puede ser por email, teléfono, el documento físico, una charla de pasillo, una sesión específica, o cualquier otra forma o una combinación de ellos. Elijas los que elijas, respétalos y no permitas que entre nada que llegue por fuera de esos canales.

Establece que persona o personas pueden decidir si una petición entra o no en el Backlog. Lo normal sería que fueran los Product Owner, ya que son los responsables de que el Backlog esté en condiciones. Pero tampoco pasa nada si otras personas del equipo les ayudan en esa labor.

No seguir este procedimiento, tiene dos consecuencias principales:

    • Si has establecido unos Criterios de Aceptación, no aseguras su cumplimiento.
    • Tendrás elementos en el Backlog que no son conocidos por el Product Owner. Y, por tanto, el peticionario tendrá unas expectativas que es muy probable que no se cumplan.
\

Divide sólo lo necesario

Si hablamos de elementos listos para completarse en un Sprint, nuestra propuesta estándar es tener suficientes para 2 sprints. Con 1 sprint tengo poco margen de maniobra para reducir la incertidumbre. Con más de 2 estoy dedicando esfuerzo en elementos que puede que no se realicen, dependiendo del nivel de variabilidad que tenga.

Esa misma idea la llevamos a los Backlog de Portfolio. Considerando ciclos trimestrales, es suficiente con tener elementos que se pueden realizar en un trimestre para 2 trimestres. Fíjate que hablamos de tener una visión a 6 meses de lo que queremos que ocurra. Piensa en la situación actual de pandemia y con el nivel de incertidumbre que hay, si eres capaz de asegurar tu plan a 6 meses.

\

Utiliza técnicas de priorización

Usar técnicas como MoSCoW o Kano te ayudará a detectar los elementos del Backlog que puedes descartar directamente porque no son necesarios o no satisfacen al cliente ahora. Luego puedes decidir qué elementos deben quedarse y cuáles no.

Aunque suele ser más interesante utilizarlas a nivel de Portfolio, no descartes hacerlo también una vez divides un PBI en elementos para el Sprint. Incluso dentro de los elementos obligatorios puede haber partes que no sean necesarias.

\

Elimina los elementos antiguos

Te pregunto ¿de verdad esa petición que lleva 2 años en el Backlog era tan importante? ¿Y sigue siendo necesaria 2 años después? O incluso, una vez finalizado el año fiscal y revisados tus objetivos estratégicos, ¿Todo lo que queda en el Backlog sigue siendo relevante?

Establece un tiempo de vida para los elementos del Backlog. Es así de sencillo. Una vez superado, elimínalos y comunica a su peticionario que los consideras obsoletos. Por supuesto, te recomiendo realizar esta acción bajo el más absoluto consenso.

No tengas miedo de eliminar elementos del Backlog, si algo es realmente importante para la empresa va a llegar de nuevo.

Una vez tengas definidos los límites y las políticas para tu Backlog, es súper importante la comunicación a todos aquellos que deben cumplirlas. Deben ser conocidas, visibles y de fácil acceso para toda la empresa.

Mi consejo es que al principio seas riguroso en su cumplimiento, y que según vayas teniendo experiencia las revises y ajustes a la realidad de tu empresa. E incluso qué excepciones pueden ocurrir.
Como siempre aconsejamos, no intentes cubrir absolutamente todo al principio, o serán tan complejas que te bloquearán y no entrará nada, o entrará todo con los “y si…”.

Mi Backlog ya es eterno

¿Qué hago si ya tengo un Backlog eterno? Mi recomendación: establece criterios, un procedimiento, y una temporalidad, y aplícalos a tu Backlog actual. Todo lo que no esté dentro de lo establecido, elimínalo.

Resumen

Evitar que nuestro Backlog se convierta en eterno es fácil estableciendo unos criterios y procesos de llegada claros, transparentes y conocidos por todos en la empresa. Su principal función es ayudar a los Product Owner a decidir qué entra y qué se queda fuera del Backlog, facilitando el que puedan decir “ahora no” en base a criterios y argumentos objetivos.

Espero que estos consejos te ayuden a mantener el Backlog limpio. Puede ser complicado incorporar todo a tu día a día. Para entender cómo empezar te dejo algunas preguntas que seguramente te sirvan de guía:

W

¿Qué cosas encajan con tu equipo y cuáles no?

W

¿Qué te gustaría poner en marcha de lo que te hemos contado? Y de cada cosa, apunta:

Qué pasa si no lo intentas.

Qué pasa si lo intentas y lo consigues.

Qué pasa si lo intentas, pero no lo consigues.

Quiénes son tus aliados claves para introducir ese cambio y cómo los vas a implicar.

Con esta información, prioriza y elige qué vas a hacer primero. Y luego ven y cuéntame cómo te ha ido.

También te puede interesar.

El Product Owner: el desconocido y olvidado

Desde hace tiempo tengo la sensación que se desconoce la función de un Product Owner.

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.

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.

Es importante usar Historias de Usuario

Usar Historias de Usuario es importante para los Product Owner, además de la más utilizada a la hora de escribir el Product Backlog.

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.

Apoya a tu equipo entendiendo qué le ocurre

La transparencia es uno de los pilares de Scrum. Con ella conseguimos hacer visible lo que ocurre dentro del producto, equipo, personas, … para hacer inspección y adaptación. ¿Cómo podemos saber qué ocurre en el equipo para poder apoyarle?

Aprendiendo en un Equipo Scrum

El conocimiento compartido potencia a tu equipo. Aquí descubrirás cómo identificar las áreas de conocimiento y favorecer su aprendizaje continuo

¿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.

El Product Owner y su relación con los Stakeholders

Como Product Owner enseguida te has dado cuenta de la gran importancia que tiene tu relación y la del Equipo Scrum con los Stakeholders.

Lo que te estás perdiendo por hacer «tu» Scrum

¿Qué ocurre si decides utilizar sólo parte de Scrum? Dejar de usar roles, eventos o artefactos tiene sus riesgos.

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