Estando en medio de unas de estas aventuras que supone resolver tareas cotidianas, y al ver las montañas de nieve a los lados de cada calle, he recordado una analogía que leí en un blog, que trataba de explicar el problema que surge frecuentemente con la gestión del Backlog en equipos Scrum maduros.
Cuando comenzamos a trabajar en el desarrollo de un producto Agile, generalmente es sencillo disponer de un Backlog bien construido, gracias a la implicación y entusiasmo de todo el equipo, especialmente del Product Owner. En ocasiones será necesario fragmentar algunos de los items propuestos, para garantizar que los resultados pueden lograrse en sprints individuales. O tendremos que estudiar y negociar con el Product Owner la conveniencia de modificar el orden de prioridad. Pero, con mayor o menor esfuerzo, lograremos alcanzar un momento en el que daremos el Backlog por supuesto. Alcanzar este punto proporciona un estado de confianza recomendable. Pero, como en tantas otras ocasiones, también puede llevarnos a un exceso de confianza en el que el Backlog se puede convertir en un cajón donde vamos a buscar el objetivo del siguiente sprint, pero también donde vamos amontonando, con bastante descuido y falta de orden, las propuestas de funcionalidades futuras para nuestro producto.
Los riesgos principales de esta situación son:
- En primer lugar, puede ocasionar una pérdida de foco en el objetivo del producto. Si el Product Owner no delega excesivamente sus funciones, el resto del equipo puede comenzar a orientar su atención a funcionalidades que no son prioritarias para el producto, aunque indudablemente tendrán interés, e incluso puedan aportar valor. Pero no tendrán la relevancia necesaria de cara al valor percibido por el cliente.
- En segundo lugar, los items en el Backlog deben ser revisados con cuidado para garantizar que su resultado puede obtenerse en un único sprint. Recuerda el acrónimo DEEP (Detailed Appropriately, Estimated, Emergent, Prioritized). Esto requiere de un análisis funcional y técnico preciso, que realice la fragmentación necesaria de manera que resulte coherente y evite añadir sobreesfuerzos innecesarios.
La aparición de estos 2 riesgos nos puede poner en la misma situación en la que muchos nos hemos visto estos días cuando, contentos al ver que la máquina quitanieves ha pasado por nuestra calle limpiando el hielo y la nieve acumulados, nos hemos llevado la enorme decepción de comprobar que toda la nieve apartada de la vía de circulación ha sido arrojada hacia los lados bloqueando e impidiendo la salida de los vehículos aparcados. De manera que la propia operativa que nos proporciona la oportunidad de poder circular, es la misma que nos ha generado el mayor inconveniente para ser capaces de ponernos en marcha, justo en el punto de partida.
Ese amontonamiento de nieve es equivalente al que nos arriesgamos a encontrar con los items de nuestro Backlog, ni no lo administramos adecuadamente. Probablemente convenga que en nuestro equipo de producto utilicemos herramientas de decisión más delicadas que el quitanieves.
Imágen: Pixabay en pexels.com.