Cycles sin velocity game: salir del teatro Scrum

En este preciso momento hay una reunión de planificación de sprint en cientos de empresas. El equipo está reunido, el backlog está abierto. Y en algún lugar de la sala, alguien dice: “Si queremos mantener nuestra velocity, deberíamos limitarnos a 40 puntos en este sprint.”

Lo que revela esa frase: el equipo no planifica para entregar valor. Planifica para mantener una cifra estable.

Eso es el velocity game. Y es una de las patologías más extendidas del Scrum en las empresas.

De dónde viene la velocity

La velocity nació de una buena intuición: medir la capacidad de un equipo para entregar trabajo en un período determinado, con el fin de planificar los períodos siguientes de forma realista.

La idea base es sana. Si un equipo lleva tres meses entregando una media de 35 story points por sprint, es razonable planificar los próximos sprints a 35 puntos. Es predictibilidad empírica, no planificación al azar.

El problema empieza cuando esta métrica de predicción se convierte en una métrica de evaluación.

Cómo la velocity se convierte en un objetivo

La ley de Goodhart dice aproximadamente: cuando una medida se convierte en un objetivo, deja de ser una buena medida.

Eso es exactamente lo que ocurre con la velocity.

Al principio: el equipo estima los tickets en story points para planificar de forma realista. La velocity se observa, no se pilota.

Unos meses después: el manager empieza a revisar la velocity en los informes de Jira. Pregunta si la caída de velocity en un sprint es “preocupante.” El equipo empieza a defender su velocity en las reuniones.

Un año después: el equipo estima los tickets eligiendo valores que mantienen la velocity estable. Los tickets grandes se fragmentan para no superar un umbral cómodo. Los pequeños se agrupan para alcanzar el mínimo. Los criterios de aceptación se ajustan en función de los puntos disponibles, no de las necesidades reales.

La velocity es ahora un objetivo. Y como objetivo, empuja al equipo a optimizar para sí misma, no para el valor entregado.

El teatro Scrum

El velocity game es uno de los síntomas del teatro Scrum: respetar las formas de un método sin conservar su espíritu.

El teatro Scrum se parece a esto:

Daily standups de quince minutos que duran cuarenta y cinco y terminan con “hablamos por DM.” Todo el mundo responde a las tres preguntas rituales. Nadie señala realmente lo que le bloquea.

Sprint reviews donde el equipo presenta lo entregado pero los interesados no dan feedback real porque las decisiones importantes ya se tomaron en otro lugar.

Retrospectivas donde se listan los mismos problemas cada sprint, con las mismas acciones que nunca se implementan porque requerirían cambios estructurales que el Scrum Master no tiene mandato para hacer.

Planificaciones de sprint donde los tickets se estiman en siete minutos cada uno porque hay demasiados y la reunión debe terminar antes del mediodía.

La forma está ahí. El fondo ha desaparecido.

Lo que los cycles pueden hacer de forma diferente

Un cycle no es necesariamente mejor que un sprint. No es un método con manual de uso. Es simplemente un período de tiempo delimitado para organizar el trabajo.

Lo que abre como posibilidad: definir el cycle en función de lo que hay que hacer, en lugar de seguir una cadencia impuesta.

Un cycle puede durar dos semanas, cuatro semanas, seis semanas, según lo que haya que hacer y cómo trabaje el equipo. Puede tener una temática: “En este cycle nos centramos en el rendimiento de la página de inicio.” Puede tener un objetivo medible: “Al final de este cycle, el tiempo de carga es inferior a 2 segundos.”

La diferencia fundamental: el cycle se define por su objetivo, no por su duración. La duración es una restricción que ayuda a definir un objetivo alcanzable, no al revés.

Estimar sin story points

Una de las formas de salir del velocity game es cambiar la manera de estimar.

Se supone que los story points representan la complejidad relativa del trabajo, no el tiempo. En la práctica, en la mayoría de los equipos, representan el tiempo. Y se manipulan en función de la velocity objetivo.

Alternativas que han demostrado su eficacia en algunos equipos:

El T-shirt sizing. XS, S, M, L, XL. Menos preciso, pero más honesto sobre la naturaleza de la estimación. No se pretende saber si algo lleva 3 puntos o 5 puntos. Se sabe si es pequeño, mediano o grande.

La estimación probabilista. En lugar de una cifra, una horquilla: “Este trabajo lleva entre 2 y 5 días según las sorpresas que encontremos.” Más realista, más difícil de manipular.

Sin estimación alguna. Algunos equipos, especialmente en el movimiento #NoEstimates, han dejado simplemente de estimar a este nivel de granularidad. Siguen el número de issues completadas por período en lugar de puntos hipotéticos.

Ninguno de estos enfoques es universalmente mejor. Lo que sí es universalmente cierto: cualquier métrica de estimación puede jugarse si se convierte en una métrica de rendimiento.

Lo que desplaza el objetivo de cycle

Cuando un cycle tiene un objetivo claro - un resultado esperado, no solo una lista de tickets - algo cambia en la forma en que el equipo toma decisiones durante el proceso.

Con una velocity que mantener: cada decisión se filtra con “¿esto me acerca a mis puntos?” Una issue imprevista importante pero fuera del alcance del sprint genera tensión. Si la aceptas, no llegas a la velocity. Si no la aceptas, ignoras algo importante.

Con un objetivo de cycle: cada decisión se filtra con “¿esto me acerca al objetivo?” Una issue imprevista importante está dentro del perímetro del objetivo (se acepta) o fuera de él (se anota para el siguiente cycle). El arbitraje es más natural.

El objetivo de cycle también proporciona un criterio de éxito independiente de las métricas de entrega. “¿Alcanzamos el objetivo de este cycle?” es una pregunta que se puede responder con sí o no, con argumentos sustanciales. “¿Mantuvimos nuestra velocity?” es una pregunta a la que siempre se puede responder afirmativamente si se han calibrado bien las estimaciones.

Los rituales que tienen sentido

El hecho de que exista el teatro Scrum no significa que todos los rituales de Scrum sean inútiles. Algunos tienen valor real, siempre que se practiquen por la razón correcta.

La sincronización diaria tiene valor cuando sirve para detectar bloqueos reales. No para dar un informe de estado. La pregunta útil no es “¿qué hiciste ayer?” sino “¿hay algo que te impida avanzar hoy?”

La revisión de fin de cycle tiene valor cuando produce feedback real de personas que usan o van a usar lo que se entregó. No una demo para confirmar que los tickets están cerrados.

La retrospectiva tiene valor cuando produce acciones concretas con un responsable y una fecha límite. No una lista de puntos positivos y negativos que desaparece en Confluence.

Lo que tienen en común estos rituales cuando funcionan: producen decisiones, no actas.

La pregunta que pocos equipos se hacen

Al final de un cycle, ¿qué pregunta se hace el equipo?

En muchos equipos Scrum: “¿Cerramos los tickets previstos?” Si es así, el cycle es un éxito. Si no, se busca qué lo bloqueó.

Una pregunta más útil: “¿Qué pueden hacer los usuarios ahora que no podían hacer antes de este cycle?”

Si la respuesta está vacía - si todo lo que se hizo durante el cycle fue deuda técnica, refactorización interna, infraestructura - no es necesariamente un problema. Pero es información. Dice que este cycle no creó valor directo para los usuarios, y el equipo debería poder explicar por qué fue la decisión correcta.

Si la respuesta existe pero es vaga - “mejoramos el rendimiento general” - eso también es información. Dice que el equipo tiene dificultades para articular el valor de lo que entrega.

La capacidad de responder claramente a esta pregunta es uno de los mejores indicadores de la salud de un equipo de desarrollo.

Salir del velocity game sin romper todo

La mayoría de los equipos no pueden abandonar los story points mañana. Están integrados en los informes, en los compromisos con la dirección, en los hábitos de trabajo de años.

Lo que puede cambiar de forma gradual:

Empezar añadiendo un objetivo explícito a cada cycle, aunque se mantengan los puntos. El objetivo se convierte en la conversación principal. Los puntos permanecen para la predictibilidad.

Reducir el número de tickets por cycle en lugar de inflar las estimaciones. Menos tickets, mejor definidos, con criterios de aceptación precisos.

Evaluar el cycle por el objetivo alcanzado, no por su velocity. Progresivamente, la mirada del equipo se desplaza.

La velocity puede seguir siendo un indicador de capacidad. Pero cuando el objetivo del cycle se convierte en el criterio de éxito principal, el velocity game pierde su interés.

El problema no es el sprint. Es confundir la duración del sprint con el objetivo del sprint. Y confundir la velocity con el valor.

Un cycle bien definido no necesita 42 puntos para saber si tuvo éxito. Necesita una pregunta clara: al final, ¿qué habremos entregado, y a quién sirve?