Cuando el sprint superó al equipo: una historia de planificación de la capacidad
Un equipo de servicios municipales —llamémoslo el escuadrón de Permisos— acudió a nosotros frustrado a finales de 2021. Había adoptado Scrum dieciocho meses antes, la mitad del equipo ya trabajaba a distancia y cada sprint terminaba igual: una pila de trabajo sin terminar que pasaba al siguiente. Los gráficos de velocidad parecían ocupados, pero la entrega estaba atascada. El Scrum Master sospechaba que el equipo era simplemente lento. Los datos contaban otra cosa.
Lo que en realidad faltaba era una planificación honesta de la capacidad. La Guía Scrum no prescribe una fórmula, pero la Planificación del Sprint pide explícitamente a los desarrolladores que pronostiquen lo que pueden terminar de forma realista. Este equipo pronosticaba con esperanza. Al desglosar sus últimos seis sprints vimos a un equipo que se comprometía con unos 40 puntos y terminaba alrededor de 28. La brecha no era de esfuerzo, sino de una aritmética que nadie había hecho.
A dónde iban realmente las horas
Hicimos una contabilidad sencilla de un solo sprint de dos semanas para un desarrollador. Diez días laborables no significan diez días de trabajo de sprint. Una vez restadas las reuniones, la rotación de soporte y el simple hecho de que las personas no son máquinas, el número real es mucho menor — y en un esquema híbrido, el costo de coordinación sube, no baja.
Parta de los días disponibles, no del número de personas. Dos de seis desarrolladores estaban de vacaciones y un feriado caía dentro del sprint. Eso por sí solo eliminó casi el 15 % del tiempo nominal antes de empezar.
Reste las ceremonias y los compromisos fijos. Scrum diario, planificación, revisión, retrospectiva y una llamada recurrente con las partes interesadas: cerca de un día por persona durante el sprint.
Reserve para las interrupciones que sabe que vendrán. Un desarrollador estaba en soporte de producción esa semana. Fingir que ese tiempo estaba disponible era la mayor fuente de trabajo arrastrado.
Aplique un factor de concentración, con honestidad. Un desarrollador realista dedica del 60 al 70 % de sus horas nominales al sprint, no el 100 %. El cambio de contexto a distancia llevaba a este equipo al extremo bajo.
Al reconstruir el sprint sobre esos números, la capacidad real del equipo rondaba los 28 puntos — justo lo que venía terminando. No eran lentos. Planificaban un sprint que no existía.
Lo que cambiamos para el siguiente sprint
Planificar según la capacidad demostrada (su verdadero promedio terminado), con un pequeño margen en lugar de una meta exigente.
Hacer visible y restada la rotación de soporte en la planificación, en vez de un impuesto invisible.
Definir el «terminado» de forma estricta para que un elemento finalizado fuera realmente entregable, eliminando el retrabajo oculto disfrazado de trabajo nuevo.
Revisar la capacidad en cada planificación, porque la disponibilidad de un equipo híbrido cambia de semana a semana.
El resultado no fue heroico. En los tres sprints siguientes el equipo se comprometió a menos y terminó casi todo. Volvió la previsibilidad, la pila de arrastre casi desapareció y — lo que el Scrum Master no esperaba — subió la moral. La gente dejó de terminar cada sprint sintiéndose atrasada. La planificación de la capacidad no los hizo más rápidos; alineó su plan con la realidad, el único pronóstico en el que una parte interesada puede confiar de verdad.
La lección va mucho más allá de un solo equipo. Un compromiso de sprint es un pronóstico, y un pronóstico basado en el número nominal de personas en lugar de horas disponibles y concentradas fracasa al chocar con un calendario normal. Sobre todo en equipos distribuidos que aún se acomodan al trabajo híbrido, la disciplina consiste en contar lo que de verdad se tiene antes de prometer lo que se entregará.
Si sus equipos de entrega se comprometen de más y terminan de menos, la asesoría de entrega de programas y proyectos de XNM puede ayudarle a fundamentar la planificación del sprint en la capacidad real y recuperar una entrega predecible.