El tiempo de espera es el tiempo acumulado que los ítems pasan estacionados en vez de en trabajo. Es la forma más directa de sacar a la luz la fricción del flujo.
Qué mide
Las horas que los ítems estuvieron en un estado que tu board mapea a la categoría Waiting, sumadas sobre los ítems que el equipo completó en el período. El trabajo todavía en vuelo no aporta nada hasta que termina.
Cómo lo calcula Leanmote
Leanmote recorre el historial de estados de cada ítem completado y suma cada tramo que empezó en un estado de espera:
Categoría del estado | ¿Suma al tiempo de espera? |
Backlog (0) | No |
Active (1) | No — eso es tiempo activo |
Waiting (2) | Sí |
Done (3), Cancelled (4) | No |
No hay una lista incorporada de nombres de estados "de espera". Leanmote no busca
blockedniqa_pending: mira la categoría que le asignaste a cada estado en el mapeo de estados del board. Un estado llamado "Blocked" que hayas mapeado a Active cuenta como trabajo activo.Los tramos se recortan a la ventana seleccionada, así que un ítem que esperó cruzando el borde aporta solo la parte de adentro.
El promedio divide por todos los ítems completados, incluidos los que nunca esperaron.
La métrica se informa como total y promedio, ambos en horas. No se informa como porcentaje del cycle time: esa mirada es otra métrica, la eficiencia de flujo, que es activo ÷ (activo + espera) y vive en la Vista Estratégica.
Cómo interpretarlo
Compara el tiempo de espera contra el tiempo activo de los mismos ítems. Si la espera aplasta al activo, el sistema está sobre todo haciendo cola, y el arreglo está en el proceso, no en el código.
Si el tiempo de espera sube mientras el cycle time sube, el cuello de botella está en un estado pasivo.
Localiza por etapa. El estado con la mayor porción de espera es el objetivo de más palanca.
Qué hacer al respecto
Si la revisión es la espera más larga: acorta el tiempo hasta que alguien la toma, define SLAs, reparte la carga de revisores.
Si QA es la espera más larga: invierte en automatización de tests y en controles de calidad previos al merge.
Si el deploy es la espera más larga: deploya más seguido o quita compuertas manuales.
Limita el WIP: menos ítems en vuelo significa menos espera por ítem.
Si el número parece equivocado
La causa más común es el mapeo, no la medición. Un estado que nadie categorizó, o uno categorizado como Active cuando el equipo lo usa como cola, mueve horas de un balde al otro. Revisa el mapeo de estados del board antes de concluir que cambió el flujo.
Métricas relacionadas
Tiempo activo
Cycle Time
Eficiencia de flujo — los mismos dos números expresados como razón
Trabajo en curso (WIP)
Panel de Bottleneck Insights