Autoevaluación de métricas de flujo para equipos

Revisa cómo avanza el trabajo en tu equipo y compáralo con los datos de flujo de tu herramienta.

Pruebe esta evaluación de salud en directo

¿Qué es una autoevaluación de métricas de flujo?

El flujo es la forma en que el trabajo avanza dentro de un equipo, desde que se empieza hasta que se termina. La Guía Kanban define cuatro métricas de flujo que todo equipo Kanban debe medir: trabajo en curso, rendimiento (throughput), antigüedad de los elementos de trabajo y tiempo de ciclo. La mayoría de los equipos ya pueden obtener estas cifras con herramientas como Jira, Azure DevOps, Linear o GitLab. Esta evaluación pregunta cómo vive el equipo el flujo, no cuáles son las cifras. Cada persona valora en privado 10 afirmaciones sobre definiciones compartidas, trabajo visible, limitación del trabajo en curso, trabajo atascado y previsibilidad. Cuando comentes los resultados, ponlos junto a los gráficos de flujo de tu herramienta y, después, convierte las puntuaciones más bajas en acciones en una retrospectiva.

Dimensiones

Definiciones y visibilidad

Si el equipo está de acuerdo en qué es su trabajo y puede verlo en su totalidad.

  • Empezado y terminado

    Todos estamos de acuerdo en cuándo un trabajo se considera empezado y cuándo se considera terminado.

  • Trabajo visible

    Todo nuestro trabajo, incluidas las peticiones no planificadas, está visible en un solo lugar.

Limitar el trabajo en curso

Si el equipo mantiene el trabajo sin terminar lo bastante bajo como para que los elementos sigan avanzando.

  • Terminar antes de empezar

    Terminamos el trabajo que ya está en curso antes de empezar algo nuevo.

  • Límites de trabajo en curso

    Mantenemos la cantidad de trabajo en curso lo bastante baja como para que los elementos sigan avanzando.

Trabajo atascado

Si el trabajo que envejece o está bloqueado se detecta y se resuelve.

  • Primero los más antiguos

    Revisamos con regularidad nuestros elementos sin terminar más antiguos y actuamos sobre ellos.

  • Bloqueos resueltos

    Los bloqueos se comunican en cuanto aparecen y se resuelven rápidamente.

  • En trabajo, no en espera

    Nuestros elementos de trabajo pasan más tiempo siendo trabajados que parados a la espera.

Previsibilidad

Si el equipo sabe cuánto suele tardar el trabajo y lo termina a un ritmo constante.

  • Plazos conocidos

    Sabemos cuánto suele tardar un trabajo similar y planificamos en función de ello.

  • Ritmo de finalización constante

    Terminamos los elementos a un ritmo constante, no a grandes rachas.

Aprender del flujo

Si el equipo usa sus datos de flujo para mejorar su forma de trabajar.

  • Datos de flujo en las retros

    Revisamos nuestros datos de flujo en las retrospectivas y cambiamos nuestra forma de trabajar en consecuencia.

Cuándo debe realizarse esta revisión médica

  • Cuando el tablero parece muy ocupado pero apenas se termina nada.
  • Cuando los gráficos de tu herramienta muestran un problema, como elementos que envejecen o trabajo que se acumula, y el equipo necesita hablar de por qué ocurre.
  • Cuando un equipo empieza a usar Kanban o cambia su flujo de trabajo, para comprobar que lo básico está en su sitio.

Consejos y trucos

  • Lleva las cifras. La mayoría de las herramientas de seguimiento pueden representarlas en gráficos, como el gráfico de control y el diagrama de flujo acumulado de Jira, los widgets de tiempo de ciclo y lead time de Azure DevOps, Linear Insights o GitLab Value Stream Analytics.
  • Cuando las valoraciones del equipo y los gráficos no coincidan, hablad de por qué. Esa diferencia suele ser la parte más útil de la conversación.
  • Empieza por los elementos sin terminar más antiguos. Preguntar por qué está atascado cada uno suele llevar directamente al bloqueo o a la política que hay que cambiar.
  • Acordad qué significan «empezado» y «terminado» antes de comparar datos a lo largo del tiempo; si no, las cifras no significarán lo mismo de un mes a otro.
  • Convierte una o dos de las puntuaciones más bajas en acciones en tu próxima retrospectiva y vuelve a hacer la evaluación en unas semanas para ver qué ha cambiado.

Preguntas frecuentes

¿Cuáles son las cuatro métricas de flujo?
La Guía Kanban enumera cuatro. El trabajo en curso (WIP) es el número de elementos empezados pero aún no terminados. El rendimiento (throughput) es el número de elementos terminados en un periodo determinado, como una semana. La antigüedad de un elemento de trabajo es el tiempo que lleva en curso un elemento sin terminar, y el tiempo de ciclo es lo que tardó un elemento terminado desde que se empezó hasta que se terminó.
¿Qué es la antigüedad de un elemento de trabajo?
Es el tiempo transcurrido desde que se empezó un elemento que aún no está terminado. A diferencia del tiempo de ciclo, puedes verla mientras el trabajo sigue en curso, así que te avisa pronto cuando algo está atascado. La Guía Kanban pide a los equipos que se aseguren de que los elementos no envejezcan innecesariamente, tomando como referencia el tiempo esperado para terminarlos.
¿Qué relación tienen las métricas de flujo con DORA?
El lead time de cambios de DORA, es decir, el tiempo que pasa desde que se confirma un cambio en el código hasta que está en producción, es una medida de flujo de una parte del proceso. Las métricas de flujo abarcan todo el recorrido desde que se empieza hasta que se termina, incluido el trabajo previo a escribir cualquier código. Usa la Autoevaluación de métricas DORA para la entrega y esta evaluación para ver cómo avanza el trabajo en el equipo.
¿Necesitamos una herramienta para usar esta evaluación?
No. Las afirmaciones preguntan cómo vive el equipo el flujo, así que cualquiera puede valorarlas sin datos. Aun así, la conversación es mejor con cifras, de modo que si tu herramienta de seguimiento muestra el tiempo de ciclo, el trabajo en curso o los elementos que envejecen, lleva esos gráficos.
¿Cómo usamos los datos de flujo en una retrospectiva?
Revisa las afirmaciones peor valoradas junto al gráfico correspondiente, como los elementos que envejecen o el trabajo en curso a lo largo del tiempo. Preguntad qué está causando ese patrón y acordad un cambio que probar, como un límite más bajo de trabajo en curso. Revisad el mismo gráfico en la siguiente retro para ver si ha servido.
¿Quién creó La Guía Kanban?
John Coleman y Daniel Vacanti. La versión actual se publicó en mayo de 2025 en kanbanguides.org con una licencia Creative Commons. Las afirmaciones de esta evaluación son propias de TeamRetro. TeamRetro no está afiliado a los autores ni a Kanban Guides.

Based on the flow metrics in The Kanban Guide (May 2025) by John Coleman and Daniel Vacanti.

Revisiones médicas relacionadas