Publicaciones

Métricas de flujo para equipos Scrum: tiempo de ciclo, throughput y qué medir realmente

Tu equipo rastrea la velocidad. Hablan de ella en la planificación del sprint, tal vez la mencionan en las retrospectivas. Pero cuando un stakeholder pregunta "¿cuándo estará listo esto?" terminas adivinando. La velocidad te dice cuánto estimaste que completaste, no cuánto tiempo toman realmente las cosas o dónde se atasca el trabajo. Las métricas de flujo llenan ese vacío. Miden lo que realmente está sucediendo en tu proceso usando datos reales, no estimaciones. Y no necesitas abandonar Scrum o "adoptar Kanban" para usarlas.

Las cuatro métricas que importan

La Guía Kanban para Equipos Scrum (publicada por Scrum.org) define cuatro métricas de flujo. Aquí está lo que cada una te dice y por qué vale la pena rastrearla.

Work in progress (WIP)

El conteo de elementos que tu equipo ha comenzado pero no ha terminado. Sin fórmulas, solo un número. WIP importa debido a una verdad simple: cuantas más cosas haces malabares, más tiempo toma todo. El cambio de contexto, las transferencias y el tiempo de espera aumentan con un WIP más alto. La mayoría de los equipos se sorprenden cuando cuentan por primera vez su WIP real.

Tiempo de ciclo

El tiempo calendario transcurrido desde que comienza el trabajo hasta que está terminado. No son horas de esfuerzo, es tiempo de reloj de pared. El tiempo de ciclo es un indicador rezagado. Solo lo conoces después de que un elemento termina. Pero recopila suficientes puntos de datos (apunta a 30+) y puedes decir cosas como "el 85% de nuestros elementos terminan en 10 días o menos". Eso es un Service Level Expectation (SLE), y es mucho más útil que una suposición basada en velocidad.

Throughput

El número de elementos que tu equipo termina por unidad de tiempo, típicamente por sprint o por semana. Throughput es un conteo de elementos completados sin importar el tamaño. Una historia de 3 puntos y una historia de 8 puntos cuentan como uno. Esto suena como una limitación, pero en realidad es una fortaleza: evita todos los debates sobre si tus puntos son "precisos" y mide lo que realmente entregaste.

Antigüedad del elemento de trabajo

El tiempo transcurrido desde que se inició un elemento en progreso. Piénsalo como el tiempo de ciclo para cosas que aún no están terminadas. Esta es la única métrica que deberías verificar diariamente. Si la antigüedad de un elemento se está acercando a tu tiempo de ciclo típico y todavía está lejos de completarse, esa es una señal de advertencia temprana. Una vez que el elemento termina, su antigüedad se convierte en su tiempo de ciclo. Hasta entonces, es tu mejor indicador adelantado.

Cómo se conectan estas métricas

La Ley de Little conecta las primeras tres: WIP Promedio = Throughput Promedio × Tiempo de Ciclo Promedio Esto importa en la práctica. Si reduces el WIP sin cambiar nada más, el tiempo de ciclo disminuye. Tu equipo no necesita trabajar más rápido. Necesitan trabajar en menos cosas a la vez.

Si quieres...	Entonces...
Reducir el tiempo de ciclo	Reduce tu WIP
Aumentar el throughput	Termina el trabajo actual antes de comenzar trabajo nuevo
Predecir fechas de entrega	Usa percentiles de tiempo de ciclo (SLEs)
Detectar problemas temprano	Observa la antigüedad de elementos diariamente

Comenzando sin rediseñar tu proceso

No necesitas nuevas herramientas o un rediseño de proceso. Aquí hay un camino práctico.

1. Rastrea tres fechas por elemento

   Para cada elemento del product backlog, registra cuándo fue creado, cuándo comenzó el trabajo y cuándo se terminó. La mayoría de las herramientas como Jira y Azure DevOps ya capturan esto. Solo necesitas comenzar a prestarle atención.

2. Define tu flujo de trabajo explícitamente

   Escribe lo que significan "iniciado" y "terminado" para tu equipo. ¿Cuáles son las columnas en tu tablero? ¿Cuáles son las reglas para mover elementos entre ellas? Esta es tu Definición de Flujo de Trabajo, y es la base para una medición consistente.

3. Recopila datos durante algunos sprints

   No intentes analizar nada todavía. Solo deja que los datos se acumulen. Necesitas al menos 30 elementos completados para patrones significativos, lo que la mayoría de los equipos logra en 3-4 sprints.

4. Crea tu primer diagrama de dispersión de tiempo de ciclo

   Grafica cada elemento completado con su fecha de finalización en el eje x y el tiempo de ciclo en el eje y. Dibuja líneas horizontales en los percentiles 50, 85 y 95. Tu percentil 85 es un buen punto de partida para un SLE.

5. Intégralo en tus eventos Scrum

   Usa el historial de throughput en la planificación del sprint en lugar de (o junto con) la velocidad. Verifica la antigüedad de elementos en los daily scrums. Revisa las tendencias de tiempo de ciclo en las retrospectivas. Presenta el rendimiento del SLE en las revisiones del sprint.

Dónde encajan las métricas de flujo en cada evento Scrum

Estas métricas se vuelven útiles cuando las conectas a eventos que ya estás ejecutando. Planificación del sprint: Usa tu historial de throughput para pronosticar cuántos elementos puedes incluir de manera realista. "Hemos completado 6-9 elementos por sprint en los últimos 8 sprints" está más fundamentado que debatir totales de story points. Para más información sobre cómo ejecutar sesiones de planificación efectivas, consulta nuestra guía de planificación de sprint. Daily scrum: Cambia de actualizaciones de estado a flujo. "¿Qué está envejeciendo?" es una mejor pregunta que "¿qué hiciste ayer?" Si un elemento tiene 7 días de antigüedad y tu percentil 85 de tiempo de ciclo es de 10 días, el equipo debería estar concentrándose en él. Revisión del sprint: Muestra a los stakeholders tu tendencia de tiempo de ciclo y el rendimiento del SLE. "Entregamos el 85% de los elementos dentro de 10 días este sprint, en comparación con el 72% del mes pasado" genera confianza a través de la transparencia. Retrospectiva del sprint: Aquí es donde las métricas de flujo más valen la pena. Un diagrama de flujo acumulativo muestra cuellos de botella que son invisibles en un gráfico burndown, como trabajo acumulándose en revisión de código o una fase de pruebas que se queda sin recursos cuando QA es llamado a reuniones.

Métricas de flujo vs. velocidad: no es una pelea de box

La velocidad no está rota, solo es limitada. Funciona bien como una herramienta de planificación interna para conversaciones a nivel de sprint. El problema comienza cuando los equipos la usan para compromisos de entrega, la comparan entre equipos o la tratan como una métrica de rendimiento. Las métricas de flujo responden las preguntas que la velocidad no puede:

• "¿Cuándo estará listo esto?" Los percentiles de tiempo de ciclo dan respuestas probabilísticas.
• "¿Por qué las cosas están tomando tanto tiempo?" WIP y la antigüedad de elementos te muestran dónde se atasca el trabajo.
• "¿Podemos comprometernos a esta fecha?" Las simulaciones de Monte Carlo usando historial de throughput te dan niveles de confianza.

El enfoque práctico: usa ambas. Mantén la velocidad para la planificación del sprint si funciona para tu equipo. Agrega métricas de flujo para pronósticos de entrega y mejora de procesos.

Errores que hacen tropezar a los equipos

Optimizar el throughput a costa de todo lo demás. Presionar a los equipos para cerrar más elementos lleva a elegir trabajo pequeño, dividir historias artificialmente o recortar esquinas en calidad. Throughput es una herramienta de diagnóstico, no un objetivo. Ignorar la antigüedad de elementos hasta que sea demasiado tarde. El tiempo de ciclo solo te habla del trabajo terminado. Si no estás observando la antigüedad de elementos en progreso, perderás señales de advertencia. Ponlo en tu tablero o menciónalo en el daily scrum. Saltarse la Definición de Flujo de Trabajo. Sin un entendimiento compartido de lo que significan "iniciado" y "terminado", tus datos son inconsistentes y tus métricas son poco confiables. No necesita ser perfecto, pero necesita existir. Medir todo. No necesitas 15 gráficos. Las cuatro métricas de flujo, un diagrama de dispersión de tiempo de ciclo y tal vez un diagrama de flujo acumulativo cubrirán el 90% de lo que necesitas. Agrega complejidad solo cuando tengas una pregunta específica que responder.

Cómo se ve el éxito después de unos meses

Los equipos que persisten con métricas de flujo durante 3-6 meses tienden a notar algunas cosas. La planificación del sprint se vuelve más rápida porque el throughput da un punto de partida claro para la capacidad. Las retros producen elementos de acción más específicos porque estás mirando datos en lugar de intuiciones. El mayor cambio suele ser cultural. Los equipos dejan de pensar en comenzar trabajo y comienzan a pensar en terminarlo. La pregunta cambia de "¿qué debería tomar a continuación?" a "¿en qué puedo ayudar para que se termine?" Ese es el cambio que realmente mueve la aguja. Herramientas como planning poker de Kollabe ayudan con el lado de estimación de la planificación del sprint, pero las métricas de flujo te dan la previsibilidad de entrega que la estimación por sí sola no puede proporcionar.