Product Backlog Mejorado con Kanban

Como señalado en el Scrum Guide, “… Scrum es incompleto de manera intencional, solo define las partes necesarias para implementar la teoría de Scrum”. En este momento, ocurre una disfunción, no del Scrum, sino de los lectores, ya que la mayoría de las personas llegan solo hasta la palabra “incompleto”, y todo lo demás no es más que elucubraciones de pensamientos sesgados.

Volviendo al Framework Scrum, en particular al Product Backlog, donde existe la orientación teórica, es decir, es necesario buscar caminos consistentes para que pueda surgir una lista ordenada, no solo a través del proceso de refinamiento, sino también desde el origen de las demandas. Para llegar a esta tan deseada lista “priorizada”, que personalmente me gusta llamar filtrada, podemos mencionar:

¿El ítem de trabajo está relacionado con los objetivos de la organización? Este cuestionamiento, que puede venir disfrazado de una política explícita, debería ayudar al equipo en la construcción consistente de la “Meta del Producto”. Recuerden que, para entregar algo de valor, es necesario que el Product Backlog contenga ítems de valor.

Imagina que los ítems refinados han pasado por un proceso de filtrado, donde realmente han sido validados por los principales involucrados en las problemáticas del producto, y así ha sido posible “asegurar” que el ítem tenga toda la información. Casi puedo oír “está ahí en el upstream” cuando concluimos este contenido.

¿Se ha construido o analizado en qué clase de servicio puede figurar el ítem de trabajo, y con ello tener una cierta previsibilidad de cuándo realmente estará listo, respaldado por las entregas anteriores? No siempre logramos alcanzar la previsión, pero si no comenzamos a recopilar los data points para el histograma (Lead Time), ¿qué haremos, continuamos jugando a las cartas (planning poker)?

Estas son solo algunas provocaciones donde el método Kanban puede apoyar al Framework Scrum.