Gestionando imprevistos en un Sprint (Illegitimus Non Interruptus)

Ya sabemos tod@s que las interrupciones son desperdicio, producen cambio de contexto, etc. De esto ya hemos hablado en otras ocasiones, te dejé en su día un vídeo, en el canal de YouTube, y hay incluso un post muy antiguo post del 2013.

De ahí viene ese ideal de que, en Scrum, una vez que se comienza un Sprint no se cambie el alcance, no entren imprevistos, etc.

Pero ya sabemos todos que los ideales no se ajustan siempre a la realidad y, en muchas ocasiones, mantener intacto el alcance del Sprint es… imposible. Típicamente llegan bugs, urgencias, etc.

Sabemos que esos cambios de alcance en el Sprint son malos para el cambio de contexto, pero, recordemos, «bienvenido el cambio», a veces esos cambios son claves para el negocio y que, como dice una frase de Poppendieck, escribo de memoria, un cambio a ultima hora es una ventaja competitiva. Todo esto entendiendo que sólo se van a introducir cambios en el Sprint que, realmente, no podían esperar al siguiente Planning.

De esto habla un patrón de Scrum que se llama «Illegitimus Non Interruptus», no sé cómo no había en el blog ningún post sobre este patrón (gracias David López por el recordatorio), ni estaba en el listado ese que hice de prácticas (y que como tenemos curso de Agilidad avanzada en Madrid el 18 de marzo, lo acabo de incorporar al listado de patrones que trato en el curso).

El patrón habla de, asumiendo que las interrupciones son una realidad, hacer explícito un tiempo para interrupciones. Y que si se supera ese tiempo… se cancele el Sprint. Y establece la siguiente recomendación:

• El equipo crea un buffer, deja un hueco explícito en el Sprint Backlog para inesperados en base a datos históricos. El tamaño de ese «hueco» en el Sprint Backlog se calcula en función de históricos, en base a cuántos items inesperados suelen llegar por Sprint. 
• Y, ojo, aquí viene lo importante, a ese hueco, dentro del Sprint Backlog, tiene acceso directo el Product Owner (que ya sabemos que «de libro» el Sprint Backlog es sólo del equipo técnico), el coloca ahí lo que considera que es tan urgente como para tener que entrar en un Sprint ya iniciado. 
• Si se supera ese buffer se cancela el Sprint.
• El buffer no tiene que llenarse necesariamente en cada Sprint, y en este punto aplica aquel viejo patrón de “equipos que terminan antes aceleran más rápido”, que habla de no cargar al 100% a los equipos, dejando hueco para refactorizaciones, control de deuda técnica, etc.

Ya sabes, experimenta, probar a ver qué tal funciona, inspecciona y adapta. Que la agilidad te acompañe. 

• Acerca de
• Últimas entradas

Javier Garzás

Javier Garzás es Doctor (Ph.D) en Informática, con un
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.

Últimas entradas de Javier Garzás (ver todo)

• Truco (con IA o sin ella) para espiar (legalmente) a tu competencia - 6 marzo, 2025
• Lo que NO te aconsejo hacer si quieres que SI se valore tu conocimiento - 27 febrero, 2025
• Como una PIZZA te puede dar una clase magistral de IA - 20 febrero, 2025