La Guía Definitiva de Métricas de Flujo
¿Cómo obtener previsibilidad en las entregas?
18 de fevereiro de 2022

En noviembre de 2021, Zappts realizó el Mes de los Productos Digitales, con diversas conferencias y capacitaciones en línea y gratuitas. Uno de los temas abordados durante ese mes fue “¿Cómo obtener previsibilidad en las entregas utilizando métricas de flujo?”, en una conferencia dictada por Luciano Osorio, Squad Leader, aquí en la empresa.
Este texto fue desarrollado con base en todo lo que se exploró durante el evento. Para quienes deseen seguir el video, la grabación está disponible a continuación:
Para comenzar, vamos a retomar un poco el texto de nuestro CEO, Rafael Tiba, sobre “Estrategias para reducir el ‘time to market’ de productos digitales en grandes corporaciones”. En este contenido, además de la reducción del time to market, Tiba también habló sobre entender lo que sucede dentro de nuestro flujo de trabajo. En la charla de hoy, hablaremos sobre estas métricas que nos ayudan a ver este flujo y ser más previsibles en nuestras promesas y entregas.
Métodos de Estimación
Para comenzar a abordar estas métricas, necesitamos tratar sobre métodos de estimación para definir los plazos de desarrollo de proyectos.
- Story Points
Uno de los métodos más conocidos y utilizados en el mercado son los Story Points. Estos son una forma de decir cuál es el tamaño y la complejidad de lo que estás desarrollando, además de señalar cuál es el riesgo involucrado en esa actividad. Por ejemplo: si una actividad vale cinco puntos, pero no conoces mucho sobre el tema de la misma, aumentar la puntuación simboliza el riesgo de realizarla.
Existe una dinámica que se realiza dentro de Story Points para definir esta estimación, llamada Planning Poker. Normalmente, su propósito es obtener un consenso dentro del equipo sobre cuántos puntos vale una determinada demanda.
¿Cuáles son las desventajas de los Story Points?
- Es abstracto, ya que no es algo que está directamente relacionado con el día a día de quien recibe el reporte del proyecto;
- No se comunica bien con el negocio;
- No hay mapeo directo con esfuerzo/plazo;
- Funciona a corto plazo, pero las estimaciones de demandas que se ejecutarán en el futuro distante se vuelven muy volátiles y será necesaria la revisión.
- T-Shirt Sizing
El T-Shirt Sizing es una técnica utilizada para determinar el tamaño de tu demanda, siendo ellos S, M o L. Además de ser una forma aún más abstracta que los Story Points para hacer estimaciones, trae algunas dificultades:
- Es confuso. No es posible determinar, por ejemplo, cuántas S caben en una M;
- No existe relación con plazos;
- ¿Cómo trabajar con demandas que no caben en S, M o L?;
- No es posible medir cuántos S, M o L caben en la capacidad del equipo del proyecto.
- Horas/Días
También llamado horas/días ideales, este es un método muy común de estimación y tiene más proximidad con el negocio. Es más fácil hablar sobre horas y días. Sin embargo, al igual que los métodos mencionados anteriormente, tiene algunos puntos débiles.
- ¿Cuándo fue la última vez que tuviste un día ideal?
- Intenta dar una visión determinística del futuro. Terminas intentando predecir algo que aún no ha sucedido, donde muchas cosas pueden salir mal.
- Excluye colas. En este método, estimas el tiempo del trabajo que realizarás, sin considerar las colas por las que pasará.
- Otras técnicas
Existen innumerables otras técnicas que pueden utilizarse para determinar el tiempo y la complejidad de una actividad. Por ejemplo:
- Adivinación, que ocurre cuando no sabes qué vas a hacer, así que terminas teniendo que adivinar;
- Presión, que ocurre cuando el volumen de presión ejercido sobre el equipo hace que asuma estimaciones que no son reales;
- ¿Quién grita más? Esto ocurre cuando alguien del equipo hace más “ruido” para llamar la atención y tener su demanda atendida con más rapidez;
- Determinación de plazos por el cliente, o por el jefe. Aquí el equipo ni siquiera participa de las estimaciones, alguien impone un plazo cualquiera y lo convierte en verdad dentro del proyecto.
Así, concluimos que los métodos de estimación a menudo fallan porque intentan determinar cuánto esfuerzo se necesita para la ejecución del trabajo, basándose frecuentemente en “feeling” y suposiciones, y no consideran el tiempo que la demanda permanece en colas. El futuro aún no existe y, por lo tanto, es imposible determinar cuándo ocurrirán estas esperas.
Métricas de Flujo
Para continuar, es preciso entender: ¿qué es el flujo?
El flujo es el movimiento y entrega de valor al cliente a través de un proceso. Ocurre desde el momento en que dispones los materiales hasta la hora de disfrutar del producto generado. Por ejemplo: el acto de hacer un pastel.
Separar los ingredientes, mezclarlos, ponerlos a hornear y decorarlos son actos que hacen que tu actividad camine por un flujo de tareas hasta entregar el valor al cliente, que en este caso sería saborear el pastel.
Existen tres métricas de flujo, extremadamente importantes para representar cómo funciona un proceso. Son ellas: WIP, Cycle Time y Throughput.
- Trabajo en Progreso (WIP)
Para hablar sobre trabajo en progreso, primero necesitamos definir qué es el trabajo en nuestro contexto. El trabajo es cualquier unidad de valor para el cliente (referido como ítems), como por ejemplo: user story, feature, requerimiento, mejora, bug, etc.
“En progreso” significa que el trabajo ha sido iniciado y está siendo ejecutado o aguardando para ser trabajado, pero aún no ha salido del sistema (done).
Así, WIP es el conteo de todas las unidades de valor para el cliente que han entrado en un proceso determinado pero aún no han salido de él.

- Tiempo de Ciclo (Cycle Time)
Cycle Time es el tiempo que transcurre mientras el ítem permanece como WIP.
Debes estar preguntándote: “¿Necesito descontar fines de semana y feriados?”, “¿Solo cuento las horas úteis?”
Y la respuesta a estas preguntas es: no. Cycle Time es tiempo transcurrido, como un cronómetro. Está directamente relacionado con cuánto tiempo te lleva tener el producto en manos del cliente final y, por eso, está muy ligado al tema del evento sobre Time To Market.

- Vazão (Throughput)
Cuando el trabajo está en la etapa “Hecho” de todo el proceso, podemos medir la vazão del sistema.
Así, podemos definir Throughput como la cantidad de ítems que “salen” del proceso por unidad de tiempo.
Por ejemplo: En un día de trabajo es posible entregar tres nuevos cards.

¿Pero por qué usar estas métricas y no otras?
Porque estas métricas tienen poder predictivo para la pregunta más importante del cliente, que es: ¿cuándo estará listo el trabajo?
Esta es una pregunta extremadamente importante y fundamental para el cliente desde el momento de la negociación del proyecto.
Sobre todo, necesitamos tener en cuenta que el futuro no existe. Sin embargo, un futuro a corto plazo, aunque no pueda ser determinado, puede ser previsto con un cierto margen de seguridad. Cuanto más a largo plazo sea la previsión, más incierta es. Por este motivo, es necesario estar constantemente analizando estas métricas y corrigiendo las previsiones, para garantizar que la incertidumbre existente en el futuro no impacte las entregas de forma negativa.
La relación entre las métricas de flujo
Llegó el momento de saber más sobre la relación entre las métricas presentadas anteriormente y cómo determinan las respuestas para el cliente.
¿Has oído hablar de la Ley de Little?
La Ley de Little dice que cuanto mayor sea tu WIP, más tiempo te lleva entregar una unidad de trabajo, porque son tantas las cosas que suceden al mismo tiempo que no puedes concentrarte en una sola.
El Dr. Little logró traducir esto en una ecuación que dice:
“Tiempo de Ciclo promedio = WIP promedio / Throughput promedio“
Así, si el WIP aumenta y mantienes el mismo Throughput, tu Cycle Time también aumentará. Del mismo manera, si tu throughput aumenta pero tu trabajo en progreso se mantiene, el tiempo de ciclo tiende a disminuir.
Esta es una relación empírica. Es mucho más propicia para estudiar el pasado que para predecir el futuro. Esto te ayudará a entender cómo está funcionando tu proceso.
Otra cosa que necesitamos considerar es que esta es una relación de promedios. El valor promedio de cada métrica no necesita, necesariamente, representar el valor actual de cada una. Entonces, es necesario tener mucho cuidado para no caer en la tentación de usar esta ecuación para “predecir el futuro”, o si lo hacemos, considerar el riesgo asumido en tal cálculo.
La Ley de Little depende de cinco premisas, y es importante saber si están sucediendo dentro de nuestro flujo.
- La Tasa de Llegada promedio de ítems en tu sistema debe ser igual, o muy cercana, a la Tasa de Salida promedio de los mismos;
- Todo el trabajo iniciado será completado y saldrá del sistema;
- La cantidad de WIP debe ser, aproximadamente, la misma al inicio y al final del intervalo de tiempo elegido para el cálculo;
- La edad promedio del WIP no está aumentando ni disminuyendo;
Cycle Time, WIP y Throughput se medirán utilizando unidades consistentes.
Cuando las premisas se cumplen, el Cycle Time promedio aproximado es constante.

Cuando las premisas se rompen, no es posible determinar el Cycle Time promedio aproximado, debido a la acumulación de WIPs.

Herramientas Analíticas
A continuación, tenemos un gráfico de Tiempo de Ciclo utilizado para medir un proyecto de Zappts. Cada uno de estos puntitos coloridos es una demanda que fue entregada. Las líneas horizontales que existen en este gráfico, donde tenemos los porcentajes, muestran que la mitad del trabajo que se hizo en este proyecto fue entregado en hasta 6 días. La otra mitad fue entregada en un poco más que eso. Por ejemplo, al mirar la línea que apunta al 85%, vemos que la mayoría de las entregas se hicieron en hasta 19 días.

El poder de este gráfico es que, con él, puedes predecir cómo se comporta el tiempo de ciclo. Cuantos más puntos tenemos en él, más se puede confiar en esta predicción.
Otra forma de seguir el Cycle Time es mirar un histograma. Este es un gráfico que cuenta cuántas veces ocurrió cada tiempo de ciclo.

Observando el gráfico, podemos ver que, en la mayor parte de las veces, el Cycle Time fue bajo. Los tiempos muy altos ocurrieron, pero en menor cantidad. Esto es exactamente lo esperado.
Ahora, observa el gráfico de Throughput a continuación. También es un histograma, y el concepto es el mismo del gráfico de Cycle Time: demuestra el conteo de la frecuencia en que ocurren determinadas vazões.

En el caso de este proyecto que usamos como ejemplo, es posible ver en el gráfico que podemos predecir al cliente, con 85% de posibilidad, que entregaremos dos ítems por día.
En este otro gráfico a continuación, organizado por semanas, es posible determinar cuántas entregas se hicieron a lo largo del tiempo.

Pensando que tus sprints tengan una duración de 2 semanas, imagina que tu cliente te pase 15 ítems para ser entregados dentro de este tiempo. Analizando el tipo de gráfico anterior, es posible decir si puedes, o no, comprometerte con estas entregas.
Volvendo a hablar sobre WIP, el gráfico a continuación muestra cómo es posible evaluar el envejecimiento del trabajo en progreso.

Las franjas coloridas corresponden a los porcentajes de consumo en cada una de las fases. Si un ítem está cerca de la franja roja al inicio, hay grandes posibilidades de que termine su paso por el sistema con un tiempo de ciclo muy alto. Sabiendo esto con anticipación, es posible tomar acciones que resuelvan este problema.
Esta es una de las análisis más poderosas e importantes para tener control y estabilidad en las métricas de flujo, y necesita un seguimiento constante.
En el gráfico a continuación, tenemos la visión del historial de trabajo en progreso a lo largo del tiempo.

Otra herramienta importante y poderosa que utilizamos es el Seguimiento del Flujo Acumulado. Con él, es posible hacer el análisis del Cycle Time por fase del proceso.

Este es un gráfico extremadamente informativo, y podemos extraer diversas informaciones que ayudan, incluso, a analizar las premisas de estabilidad y previsibilidad de la Ley de Little.
Cada uno de estos espacios coloridos dentro del gráfico representa la cantidad de ítems que tenemos en cada momento, en cada una de las fases del proceso.
Otro método de análisis, demostrado en histograma, que podemos utilizar es la Eficiencia de Flujo. Es ella la que compara el tiempo de trabajo de cada ítem con el tiempo real que se utilizó hasta su entrega, y dice qué fue realmente trabajo realizado y qué fue tiempo de espera.

Podemos observar que, en este ejemplo, hay casos donde la eficiencia fue del 100%, pero también hay casos donde la eficiencia fue baja. En estas situaciones necesitamos entender por qué sucedió esto.
En casos donde tu eficiencia de flujo sea alta (mayor que 70%), vale la pena invertir tiempo en mejoras en el trabajo que realmente estás haciendo. Sin embargo, cuando el índice de eficiencia es bajo, es una señal de que el tiempo de espera del ítem aún es largo, y es necesario trabajar para evitarlo.
Nuestro penúltimo gráfico nos muestra los Análisis de Monte Carlo. Una vez que las premisas de la Ley de Little estén funcionando y tengas un proceso estable, es posible colocar estos datos dentro de un modelo estadístico y hacer predicciones. La pregunta que este modelo de análisis responde es: ¿en cuánto tiempo estarán listos estos ítems?

En el ejemplo del gráfico observamos que los ítems tienen 50% de posibilidad de estar listos el día 04, y más de 95% de posibilidad de estar listos a partir del día 14.
En el gráfico a continuación, podemos ver otra visión del Análisis de Monte Carlo. Aquí, con base en nuestra información histórica, es posible especificar la cantidad de ítems que tendremos entregados hasta determinada fecha, y pasar una información certera al cliente.

Después de presentar todas estas herramientas para analizar las métricas de flujo, viene la pregunta que no quiere callarse:
¿Cuántos datos necesito para que todo esto funcione?
Cuanto más datos mejor, cuanto más historial mejor. Pero, estadísticamente hablando, necesitamos analizar otros hechos.
- Regla de los 5 – La mediana (la línea que separa el 50% de la muestra debajo de ella) de una población estará entre el mayor y el menor elemento de una muestra de 5 (de esa población) con 97,75% de seguridad. Con 5 muestras ya es posible tener una visión de dónde está localizada la mediana;
- En una distribución uniforme, hay 90% de seguridad de que el 12º valor estará entre el menor y el mayor entre los 11 valores anteriores;
Estos hechos nos dicen que no necesitamos tener una infinidad de datos para hacer los análisis. Parafraseando a Douglas W. Hubbard, autor del libro How to Measure Anything:
“¡Tener alguna información es mejor que no tener ninguna!”
En la herramienta que usamos aquí en Zappts actualmente, a partir de 10 ítems concluidos, siempre que estos respeten las premisas de la Ley de Little, ya es posible realizar los análisis que presentamos.
Para finalizar, algunas consideraciones importantes:
- Utiliza la misma unidad de tiempo para todas las métricas (diario, semanal, quincenal, mensual, etc.);
- La Ley de Little es una relación de promedios y no debe ser utilizada para predicciones;
- ¡El tamaño de los ítems no es lo más importante!
- ¡Comienza a medir ahora!
- Cualquier cantidad de datos es mejor que ningún dato;
- ¡Esta presentación está lejos de agotar el tema!

Sobre Zappts
Fundada en 2014 por Rodrigo Bornholdt y Pablo Augusto, Zappts realiza la aceleración digital de grandes marcas con equipos de alto rendimiento. Con enfoque en el desarrollo de software, especialmente en Front-end, UX Design, Quality Assurance y Gestión de Ambientes Cloud, opera en la planificación, gestión y operación de servicios de desarrollo de soluciones digitales corporativas, gestión de ambientes y transferencia de conocimiento a través de la tecnología de información. Referencia en la creación de experiencias digitales para los usuarios, además de desarrollar soluciones innovadoras y rápidas, la empresa opera en un modelo 100% remoto, con equipos distribuidos en más de 17 estados de Brasil.
Comparte este artículo
Artículos relacionados
16 set 2026
El fin del SaaS pasivo: por qué pagarás por resultados, no por usuarios.
El modelo tradicional de precios de software basado en licencias por usuario (SaaS basado en puestos) se enfrenta a un declive inevitable para 2026.
09 set 2026
El dilema de la autonomía tímida: por qué limitar la IA a sugerir información está mermando su margen de beneficio.
Este artículo analiza el impacto financiero de esta "autonomía tímida" y aboga por la evolución urgente hacia el modelo "Human-on-the-loop" (HOTL, por sus siglas en inglés).
02 set 2026
"SaaSocalypse" es, de hecho, una crisis de arquitectura e identidad.
Este artículo realiza un análisis retrospectivo de una historia de éxito real (anonimizada) en el sector financiero, diseccionando las capas de...