Cuando la velocidad miente: la dura lección de un equipo híbrido
Un equipo de producto con el que trabajé —llamémoslo el equipo Atlas— pasó la primera mitad de 2021 repartido en tres husos horarios, la mitad desde casa y la otra rotando por una oficina semivacía. Como muchos grupos ese año, todavía lidiaba con cortes de suministro, bajas por enfermedad y el vaivén general de la recuperación pandémica. Su Scrum Master seguía con orgullo una cifra por encima de todas: la velocidad. Había subido de 28 a 41 puntos por Sprint en cuatro meses, y la dirección adoraba el gráfico. El problema era que casi nada se entregaba de verdad.
La velocidad es una herramienta de planificación útil. También es una de las medidas de Scrum con las que más fácil resulta engañarse a uno mismo. La historia del equipo Atlas vale la pena contarla porque sus errores eran corrientes, no exóticos, y la solución no exigió ninguna herramienta nueva, solo honestidad.
Cómo se alejó la cifra de la realidad
Al mirar de cerca, tres cosas inflaban el recuento sin aportar valor al cliente.
Las estimaciones se inflaron. Bajo la presión de «mostrar mejora», el equipo empezó a puntuar más alto trabajos parecidos. Una tarea que era un 3 en marzo pasó a ser un 5 en junio. El gráfico subía; el trabajo no cambiaba.
Se reclamaban puntos por trabajo inacabado. Elementos «prácticamente listos» se contaban al cierre del Sprint y luego se reabrían discretamente a la semana siguiente. La velocidad pedía prestado al futuro.
La definición de «terminado» se había erosionado. Con los testers desbordados por los horarios híbridos, «terminado» pasó a significar código fusionado, no probado ni entregable. El incremento no era realmente utilizable.
Nada de esto era deshonesto en su intención. Era un equipo intentando parecer sano mientras se hundía en silencio. Pero la velocidad había dejado de describir el valor entregado para describir el optimismo del equipo.
Devolver la honestidad
La Guía de Scrum es clara: el incremento debe cumplir la definición de «terminado» para ser entregable, y solo cuenta el trabajo terminado. Partimos de ahí. El equipo restableció una definición estricta —probado, integrado y demostrable— y acordó que todo lo que no la cumpliera pasaba al siguiente Sprint con crédito cero. La velocidad cayó a 22 en el Sprint siguiente. La dirección se inquietó. Mantuvimos la línea.
La velocidad sirve para la previsión del propio equipo, nunca como meta impuesta ni comparación entre equipos.
Estima el tamaño relativo y luego deja la escala en paz; rebasarla a mitad de camino destruye la señal.
Cuenta solo lo que cumple la definición de «terminado» en la Revisión del Sprint: sin crédito parcial, sin pagarés.
Observa la tendencia a lo largo de varios Sprints, nunca una cifra aislada; una semana ruidosa dice poco.
En cinco Sprints la cifra honesta se estabilizó en torno a 26 y, más importante, la Revisión del Sprint por fin mostró software funcionando que el Product Owner podía liberar. Las previsiones del equipo volvieron a ser fiables, lo que importaba mucho más a las partes interesadas que un gráfico halagador. El trabajo híbrido había hecho fácil ocultar la deriva; la transparencia fue la única cura duradera.
La lección es clara. La velocidad no mide nada por sí sola: solo tiene sentido junto a una definición de «terminado» que de verdad se respete. En cuanto una métrica se convierte en objetivo, la gente optimiza la métrica en lugar del resultado. Un consultor o un coach pueden ayudar, pero sobre todo el equipo tiene que querer la verdad más que la línea bonita.
Si tus métricas de entrega cuentan una historia que no coincide con lo que envías, la asesoría de XNM en realización de programas y proyectos puede ayudarte a reconstruir medidas en las que tus partes interesadas puedan confiar.