Sobre Roadmaps ágiles, una visión a largo plazo sin comprometer el cambio

Estas primeras semanas del año han arrancado fuertes, y, curiosamente, con el tema que más me he topado, agil-profesionalmente hablando, es con… EL Product Owner. Ese rol tan clave como, demasiadas veces, ausente, al que le he dedicado tantos y tantos post. En navidad, además, se junto que terminamos la migración de la antigua plataforma de formación on-line de 233 y que inauguramos la nueva con un curso on-line de… Product Owner. Y se ha dado que hasta, por mi amor incondicional al rol, hace unas semanas, le dediqué uno de los dibujos de los jueves al Product Owner.

Por continuar con el tema, el caso es que la semana pasada estaba con unos amigos en Vigo y, entre otras cosas, salió aquello de cómo de grande debería ser un Backlog, cuantos Items, cuántas Historias debería tener, con cuánto debería arrancar un Product Owner. Decir un número no tiene sentido, y en esto no hay reglas-normativas invariantes (por mucho que se empeñe algún policía de Scrum), pero si que la regla, y el sentido, dice que «pocos» Items deberían ser necesarios para empezar, los pocos necesarios para el siguiente, y quizá el próximo Sprint.

Las ideas de por qué habría que mantener los Backlogs a dieta ya te las he contado en otros post, y no me voy a extender este en este punto, para ello yo me leería aquello de interiorizando el significado del Dual-Track, el de #ContinuousDiscovery o el de la información irrelevante en una especificación o Product Backlog suele conllevar a mayores estimaciones.

Tener un gran Backlog, grande en el sentido de con muchos Items, viene en muchas ocasiones de la necesidad de tener una idea clara de qué esperamos tener dentro de mucho tiempo. Pero especificar con mucho detalle qué queremos tener dentro de mucho tiempo huele a fase de especificación de requisitos, con el probable desperdicio de retrasar el comienzo, puede llevarnos a especificar cosas que luego no se lleguen a implementar, llevarnos por el camino del «no cambio», al haber especificado mucho y haberlo comprometido, etc.

Para evitar los problemas de especificar mucho, y tener visibilidad a largo plazo, en otras ocasiones te he hablado sobre los Roadmaps en un modelo de trabajo ágil (como en aquel post de 2013, cómo gestionar qué esperamos de un proyecto ágil: temas, epopeyas e historias de usuario). Y hoy vuelvo a sacar el tema dejándote un dibujo que hice en el avión cuando venía de Vigo.
jgarzas_233_relacion_tiempo_abstraccion
La idea es que los compromisos a más largo plazo los manejes con herramientas de mayor abstracción, es decir, de menor nivel de detalle, como son el uso de Temas y Epics. Y que el mayor nivel de detalle lo dejes para el corto plazo, para el Sprint, o Sprints, siguientes.

Los casos problemáticos vienen de hacerlo al revés, como en los cuadrantes A y D del dibujo. El más típico es el D, pasarle «al cliente» un centenar de historias de usuario acotando, en ocasiones incluso firmando, entregas a mucho tiempo, con lo que conlleva en rigidez, predictivilidad, probable desperdicio, etc.

Si estás en alguna de esas situaciones, espero que el dibujo te valga, para reafirmarte en lo que estás haciendo o para plantearte nuevas opciones en tu modelo de trabajo actual.

1 comentario en “Sobre Roadmaps ágiles, una visión a largo plazo sin comprometer el cambio”

  1. Hola Javier, excelente gráfico, el tema es, cómo hacer un roadmap o plan general sin caer en la vieja fase de «elicitación de requerimientos», pero de todas maneras lograr un plan para tener un rumbo hacia donde ir?

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba