teams

---

sidebar_label: Equipos

Módulo de Métricas: Equipos

Introducción

La página inicial del Módulo Métricas es la página de equipos; muestra una visión del desarrollo de los equipos a través del tiempo. Es posible a través de esta página verificar la madurez del equipo mediante la matriz de madurez y acceder a diversas métricas de desarrollo accediendo a la página del VSM (Value Stream Mapping). Esta visión permite al usuario tener un mayor control sobre los diversos contextos que abarcan sus equipos y de esta forma tomar medidas para su evolución.

Página Inicial

La página inicial del módulo Métricas es la página de Equipos. Está compuesta por: un selector de elección de matriz; un gráfico donde es posible visualizar la matriz seleccionada y una lista de todos los equipos de la organización.

Matriz

La matriz está compuesta de categorías e indicadores que pueden ser personalizados según las necesidades de la organización. Para cada indicador es posible agregar un valor y con eso generar una puntuación general para cada equipo. La página inicial de Equipos muestra un gráfico con esta puntuación a través del tiempo, donde cada línea representa un equipo de la organización. Es posible también, en este gráfico, visualizarlo sin los valores, desactivando el botón de alternancia (toggle) de "Etiqueta de datos" justo encima del gráfico. Esto permite una mejor visualización de la curva de evolución o decaimiento de los equipos. Es posible también que una organización tenga más de una matriz; en ese caso, se puede alternar entre ellas a través del selector "Elija una matriz". Al hacer clic sobre "Ir a Matriz", se abre la página de "Madurez del Equipo".

Lista de Equipos

Además de la matriz, en la página inicial de Equipos, es posible visualizar una "Lista de Equipos" de la organización. Al lado del nombre de cada equipo hay 4 ítems: el primero lleva al usuario a la página del Value Stream Mapping (VSM), que se discutirá posteriormente; el segundo ítem funciona como un semáforo y muestra un color agregado a la puntuación del equipo dentro del VSM, rojo para una puntuación baja, amarillo para atención y verde para una puntuación buena. La puntuación que guía estos colores es configurada por la organización. El tercero muestra la adherencia, que se calcula a través de las respuestas de la matriz seleccionada; y el cuarto representado por un lápiz es donde respondemos a los indicadores de la matriz.

Al hacer clic sobre el cuarto ítem, el usuario es dirigido a una página donde es posible visualizar la matriz en gráficos más puntuales, mostrando el resultado de las respuestas para los diversos indicadores y categorías de la matriz. También es posible agregar valor a cada indicador que define la matriz seleccionada. Para responder a los indicadores basta hacer clic en ellos en la lista mostrada a la izquierda de la pantalla. Estos valores se utilizan en la construcción de la matriz en relación con el tiempo.

VSM

La página del Value Stream Mapping (VSM) tiene como objetivo mostrar diversos indicadores, cálculos y gráficos. Indicando el avance y evolución de los equipos en relación con sus estimaciones y entregas dentro de los Sprints o Períodos. Estos datos se obtienen directamente de la plataforma de gestión del cliente, permitiendo que los indicadores y gráficos estén siempre actualizados y acordes con la realidad.

Para comenzar a utilizar la página del VSM es necesario primero entender algunos factores, como la adición, edición y eliminación del sprint/período, la personalización de la página y sus configuraciones.

Agregar un Sprint o Período

El primer paso es verificar para qué sprints o períodos se desean generar los cálculos; es necesario entonces agregar un sprint o período. Para esto, se hace clic sobre agregar y se abrirá un modal.

Para agregar un sprint basta seleccionar el checkbox superior y luego buscarlo a través de su ID o nombre. Estos datos deben ser iguales a los proporcionados en la plataforma de gestión utilizada por el cliente, ya que es de allí de donde se obtienen los datos para la realización de los cálculos. El período se agrega seleccionando el checkbox inferior y es necesario darle un nombre y definir una fecha de inicio y de fin del período. Al hacer clic en "Agregar", el sprint o período será añadido a la lista.

Editar un Sprint o Período

Al hacer clic sobre el ícono de lápiz, es posible editar el sprint/período. Se abre entonces un modal. Este modal permite: editar el nombre del sprint/período; visualizar la fecha de inicio y fin del sprint y en caso de períodos es posible editar también estos valores. Definir un número de desarrolladores y de QAs; y también agregar algunas observaciones.

Eliminar un Sprint o Período

Al hacer clic en el ícono de papelera, es posible eliminar un sprint/período. Se mostrará entonces un mensaje para validar la intención del usuario y minimizar la posibilidad de eliminación accidental. Al eliminar un sprint/período, no será modificado dentro de la plataforma de gestión utilizada por el cliente; así que si es necesario agregarlo nuevamente, basta seguir el proceso de agregar sprint/período descrito anteriormente.

Si el sprint/período está cargado en una pestaña no será posible eliminarlo; aparecerá un mensaje de alerta para que primero se elimine la pestaña y luego se intente nuevamente la eliminación.

Cargar Datos

Después de agregar sprints o períodos, se puede seleccionar cuáles se desea visualizar y hacer clic en "Cargar datos". Después de esta acción, todos los sprints/períodos seleccionados se dispondrán en pestañas. Al cargar un sprint/período por primera vez, se realizará una búsqueda de todos los datos necesarios para la realización de los cálculos y montaje de los gráficos. Esto puede demorar un poco, dependiendo de la cantidad de información que el equipo tenga en su backlog.

Reordenar

Después de la carga de los datos, cada sprint/período se dispondrá en una pestaña correspondiente. Al cargar más de un sprint/período también se creará una pestaña de comparativo que muestra diversos indicadores de comparación entre los sprints/períodos abiertos en las pestañas. Este comparativo tiene en cuenta el orden en que están las pestañas de sprint/período; por lo tanto, puede ser necesario reordenarlas. Tanto para su utilización en comparativo como para tener una mejor visualización, la reordenación puede ser útil. Después de hacer clic en "Reordenar", que está debajo de la lista de sprints/períodos, se abrirá un modal donde es posible arrastrar los sprints/períodos para que queden en el orden deseado. Después de seleccionar el orden, el usuario puede hacer clic sobre "Cancelar" y la modificación no se aplicará, o sobre "OK" y entonces las pestañas aparecerán en el nuevo orden.

Configuraciones

Al ser añadida al AI Cockpit, una organización es configurada; sin embargo, es posible realizar algunas modificaciones por equipo si es necesario, haciendo clic en Configuraciones, debajo de la lista de sprints/períodos. Las configuraciones están separadas en seis factores: Básico, Tipos, Compromiso, Flujo de Trabajo, Organización y Otros. Tienen como objetivo guiar los cálculos ejecutados hacia la realidad del equipo.

Después de realizar cualquier modificación en las configuraciones es necesario recalcular todos los sprints/períodos para que puedan ser actualizados con las nuevas configuraciones.

Personalizar

Es posible también personalizar la página para que se muestren solo los indicadores y gráficos deseados y definir en qué orden deben estar dispuestos. Para esto, es necesario hacer clic en "PERSONALIZACIÓN" debajo de la lista de sprints/períodos. Se abrirá entonces un modal para realizar estas configuraciones.

Esta página consiste en dos pestañas, donde es posible personalizar las pestañas de "Sprint/Período" y/o la de "Comparativo". También hay dos columnas de "Activos" y "Desactivados". Al hacer clic sobre un ítem, se lleva a la otra columna. Todos los ítems que estén en la columna de "Activos" se mostrarán en la página del VSM, mientras que los que están en la columna de "Desactivados" se ocultarán. Para ordenar los ítems basta arrastrarlos al lugar deseado. Los ítems más arriba se mostrarán primero en la página del VSM, por lo tanto tendrán un acceso más rápido.

Después de realizar una modificación de personalización, es posible guardarla con un nombre, permitiendo al usuario almacenar varias personalizaciones. Esto facilita el acceso a los indicadores más relevantes para su realidad en diferentes contextos.

Pestaña de Sprint/Período

Después de cargar un sprint/período se abrirá una pestaña con información de los indicadores y gráficos. Es posible realizar tres acciones relacionadas con esta pestaña, a través de los íconos mostrados en la esquina superior derecha.

• 1 - Detalle del Sprint - Hacer clic en este ícono abrirá un modal con la siguiente información sobre el sprint/período abierto: Nombre, Tipo de Compromiso, Fecha de Inicio, Fecha de Fin, Estado, Desarrolladores, QAs y Observaciones.
• 2 - Recalcular - Después de cargar un sprint/período por primera vez, puede ser necesario recargarlo (por ejemplo, cambios en las configuraciones o actualizaciones del sistema). Para hacerlo, basta hacer clic en este ícono y el proceso de recarga comenzará.
• 3 - Descartar resultados - Hacer clic en este ícono eliminará la pestaña, pero el sprint/período permanecerá en la lista de Sprints/Períodos para ser cargado nuevamente si es necesario. Después de realizar una modificación de personalización, es posible guardarla con un nombre, permitiendo al usuario almacenar varias personalizaciones. Esto facilita el acceso a los indicadores más relevantes para su realidad en diferentes contextos.

Indicadores de Sprint/Período

En esta sección, exploraremos todos los indicadores y gráficos mostrados en la página de VSM, en las pestañas Sprint/Período, para facilitar una mejor comprensión de sus contextos.

Puntuación del Sprint

Este indicador tiene como objetivo evaluar el rendimiento y el avance del sprint/período en cuestión. Se consideran cinco indicadores principales y su cálculo consiste en el promedio aritmético de estos indicadores.

Puntuación del Sprint = (Sumatoria de los indicadores)÷5

Puntuación del Sprint = (9.90 + 7.59 + 10 + 6.99 + 5.00)÷5 = 7.9

Cada uno de los cinco indicadores tiene sus propias reglas y fórmulas descritas a continuación:

Ocurrencia de Impedimentos

Este indicador varía de 0 a 10, siendo 10 un escenario donde no se encontraron bloqueos durante el sprint o período. Sufrirá una caída de valor siempre que un ítem sea bloqueado. Por eso, es inversamente proporcional al porcentaje de ítems bloqueados (% Bloqueados).

Los dos indicadores, "I" y "T", pueden encontrarse en el card de Principales Indicadores, bajo los nombres Total de horas de los ítems bloqueados y Total de horas de los ítems en Work y Wait, respectivamente.

Ocurrencia de impedimentos = (100 - (309.26÷8092.86 x 100))÷10

Ocurrencia de impedimentos = 9.62

Índice de Eficiencia

Este indicador varía de 0 a 10 y mide la relación entre:

• Cuánto tiempo los ítems estuvieron en etapas del flujo donde hay agregación de valor (WORK).
• Cuánto tiempo los ítems estuvieron en etapas del flujo donde NO hay agregación de valor (WAIT).
• Cuánto tiempo los ítems estuvieron en etapas del flujo donde hay agregación de valor (WORK), pero bloqueados.

(100 - ((A+C)÷(B+C) x 100))÷10

A = Tiempo de todos los estados en "WAIT" B = Tiempo de todos los estados en "WORK" y "WAIT" C = Tiempo en que los ítems estuvieron bloqueados en estados de "WORK"

El tiempo bloqueado C se agrega tanto en el numerador como en el denominador, ya que el bloqueo se trata como una parte significativa que afecta tanto al "WAIT" como al flujo general.

Índice de Eficiencia = (100 - ((1333.3 + 0)÷(5535.96 + 0) x 100))÷10

Índice de Eficiencia = 7.59

Los valores pueden ser alterados debido a una configuración en los cálculos del equipo. Si el cálculo de Eficiencia está activado, solo los tipos de issues utilizados en este indicador formarán parte del cálculo del índice de eficiencia. Si está desactivado, los valores se basarán en todos los tipos de issues que forman parte del compromiso.

En este indicador podemos visualizar un listado de las issues que fueron bloqueadas durante el Sprint/Período. Al hacer clic en el ícono azul al lado del valor, se muestra un modal con detalles como Tiempo de Bloqueo, Estado de Bloqueo y el Estado actual.

Para una mejor comprensión del cálculo y de qué issues se están utilizando, es posible ver el detalle de las issues haciendo clic sobre el ícono azul presentado en el card. Esto abrirá un modal.

Al hacer clic sobre la Issue-Key asociada a la issue deseada, el usuario será dirigido a su plataforma de gestión y podrá ver la issue en cuestión. También es posible realizar un filtro para mostrar solo las issues que están en bloqueo o no.

Defectos durante el Sprint/Período

Este indicador varía de 0 a 10 y mide la cantidad de defectos encontrados en el sprint o período. El valor de 10 representa un escenario donde no se encontraron story bugs o sub-bugs; este valor decaerá siempre que se encuentre uno.

En el área de compromiso de las configuraciones del equipo, hay un botón de alternancia (toggle) que activado o desactivado, altera los tipos de issues incluidas para este indicador. En el caso de que el toggle esté habilitado, las issues referentes a task y bugs serán incluidas en el cálculo de defectos durante el Sprint/Período.

(100 - (D x 100)) / 10

Cuando está desactivado "Personalizar Cálculo de Defectos" D = (Total StoryBug / (Total Story + Total Debt Tech + Total Mejora))

Cuando está activado "Personalizar Cálculo de Defectos" D = (Total StoryBug / (Total Story + Total Debt Tech + Total Mejora + Total Task + Total Bug))

Defectos durante el Sprint = (100 - (0 x 100)) / 10

Defectos durante el Sprint = 10

Compromiso Alcanzado

Compromiso son todos los ítems que fueron propuestos para ser entregados durante un tiempo determinado, que puede variar según el proceso ágil utilizado. La herramienta ofrece tres tipos de cálculo: Scrum, Kanban por Percentil de Process Time y Kanban compromiso entregado por estimado.

Este indicador varía de 0 a 10 y mide la completitud de los ítems que forman parte del compromiso del sprint o período. Al hacer clic sobre el ícono azul mostrado en el card es posible ver detalles de las issues incluidas en el cálculo además de poder filtrarlas por completadas o no.

Scrum

El cálculo se basa en el porcentaje de conclusión del compromiso (% Conclusión), encontrado junto a los indicadores de compromiso.

C÷D x 100)÷10

C = Compromiso ENTREGADO

D = Compromiso ESTIMADO

Los dos indicadores utilizados para componer la puntuación del Compromiso Alcanzado pueden encontrarse en el card Indicadores de Compromiso. Siendo C el número de Story Points Planificados y D el número de Story Points realizados.

Compromiso Alcanzado = (58÷83 x 100)÷10

Compromiso Alcanzado = 6.99

Kanban

El cálculo Kanban puede hacerse de dos formas; para alternar entre ellas es necesario modificar el botón de alternancia (toggle), que se encuentra en la página Admin > Organizaciones > Parámetros VSM en la pestaña Organización con el nombre Compromiso Kanban. Es necesario tener permisos de administrador para realizar este cambio.

Kanban por Percentil de Process Time

Si el toggle está habilitado, contabilizará solo las issues que tienen el tiempo de Process Time menor o igual al promedio del Percentil del Process Time de los últimos 3 Períodos. Este valor puede verse en los Demás Indicadores.

A continuación la fórmula de cómo se realiza el cálculo Kanban por percentil de Process Time:

(C÷D x 100)÷10

C = Cantidad de ítems entregados dentro del percentil del Process Time (Compromiso Realizado)

D = Cantidad de ítems entregados en el período actual (Issues Completadas)

Kanban compromiso entregado por estimado

Si el Toggle está deshabilitado, el cálculo será similar al del Scrum, pero es necesario realizar la configuración del "modo de control del compromiso", para considerar la lista de inicio del Kanban + Lista de tipos.

También es necesario definir en las configuraciones el campo "Estado de issues que dan inicio al compromiso del Kanban".

(C÷D x 100)÷10

C = Cantidad de ítems entregados dentro del percentil del Process Time (Compromiso Realizado)

D = Cantidad de ítems entregados en el período actual (Issues Completadas)

Con estas configuraciones realizadas, es posible realizar el cálculo. Tomando el ejemplo mostrado en la figura, todas las issues que pasen por los estados To do o To Do dentro del período seleccionado serán consideradas como Compromiso Estimado. Mientras que todas las issues finalizadas dentro del período serán consideradas las issues del Compromiso Entregado. Podemos entonces utilizar el cálculo mostrado a continuación para llegar al indicador de compromiso alcanzado.

(C÷D x 100)÷10

C = Compromiso ENTREGADO

D = Compromiso ESTIMADO

Análisis del Backlog de Defectos

Este indicador varía de 0 a 10 y tiene como objetivo medir qué tan saludable está el backlog del producto en relación con los defectos (Bug). Esta puntuación puede hacerse de dos formas y para optar entre ellas se deben tener permisos de administrador. Entonces, es necesario ir a la página Admin > Organizaciones > Parámetros VSM en la pestaña Organización y modificar el botón de alternancia (toggle) de Backlog de Defectos.

Cuando el botón de alternancia (toggle) esté configurado como no: El cálculo estará compuesto por el análisis de 3 valores:

• Defectos en el backlog del equipo no vinculados al Sprint/Período. Son los BUG's en el backlog en el primer día del sprint/período.
• Defectos creados durante el curso del sprint/período no vinculados al Sprint/Período. Son los BUG's creados después del primer día del sprint/período.
• Defectos en corrección en el Sprint/Período. Son los BUG's en corrección en el sprint/período.

nota

Se realiza una previsión considerando el ritmo actual proyectando cuántos sprints/períodos serán necesarios para llevar a cero el backlog de defectos (Bug's).

Cuando el botón de alternancia (toggle) esté configurado como sí: El Cálculo se realizará de la siguiente forma:

(100 - (((D+N)÷(E+N)) x 100))÷10

Donde:

D = Cantidad de defectos no resueltos en el backlog

N = Cantidad de nuevos bugs registrados en el período

E = Cantidad total de ítems entregados en el compromiso

Para validar los cálculos es posible obtener estos valores en "Demás indicadores". Para eso, los mismos deberán estar habilitados en las configuraciones en el lateral.

Principales Indicadores

Los Principales Indicadores, como su nombre lo indica, representan los indicadores de mayor relevancia e importancia para los cálculos y análisis realizados durante los sprints o períodos de trabajo. En este panel se presenta información detallada sobre diversos parámetros, como el total de horas de los ítems en Work y Wait, los Story Points planificados, el Lead Time promedio, el Queue Time promedio, entre otros indicadores relevantes que el usuario configure para que se muestren en la lista.

Actualmente, esta sección ofrece casi 40 indicadores diferentes para análisis, proporcionando una visión amplia y detallada del rendimiento del equipo.

Indicadores de Compromiso

El indicador de Compromiso se refiere a la capacidad del equipo de cumplir sus promesas y compromisos dentro de un ciclo de trabajo, como un sprint o período. Mide cuánto se comprometió el equipo con las tareas planificadas y la eficacia de la entrega de esos ítems. Compromiso son todos los ítems que fueron propuestos para ser entregados durante el sprint o período.

• Ítems que forman parte del compromiso del Sprint;
• Ítems que pasan por el Estado configurado como estado de compromiso.

En el módulo Métricas, es posible configurar el VSM para definir el compromiso, considerando tres opciones diferentes:

• 1. Solo lista de tipos: el compromiso se determina solo por el tipo de los ítems configurados en el campo "Tipos que forman parte del compromiso";
• 2. Considerar Flag y lista de tipos: el compromiso se determina por la lista de tipos combinada con un código de un campo específico en la plataforma de gestión; este código debe configurarse en el campo "Nombre del campo con la Flag del compromiso";
• 3. Considerar lista de inicio del Kanban y lista de tipos:
  • El compromiso se determina por la lista de estados iniciada por el estado configurado en el campo "Estado de issues que dan inicio al compromiso en el Kanban".
  • Combinado con el tipo de los ítems configurados en el campo "Tipos que forman parte del compromiso".

Conclusión del Compromiso

Este campo mide en porcentaje la completitud de los ítems que forman parte del compromiso del sprint o período. Para esto se recuperan de la plataforma de gestión dos datos:

• Sumatoria de la estimación contabilizada en el compromiso cuando el sprint o período finalizó (Total);
• Sumatoria de la estimación concluida del compromiso en el sprint o período (Concluidos).

Con ambos datos recuperados, se realiza el cálculo a continuación:

(Concluidos÷Total) x 100

Conclusión del Compromiso = (92÷115) x 100

Conclusión del Compromiso = 80

Compromiso Actual

Este campo indica el compromiso actual estimado en el caso de Story Point, Relativa o en el caso de conteo de tickets informa los ítems que entraron en el compromiso. Cuando la estimación sea Story Points o Relativa, este indicador muestra la variación de estimación de los ítems del compromiso del sprint/período a través de dos datos:

• Planificados iniciales: Sumatoria de los story points o relativa originales de todos los ítems del compromiso actual del sprint o período;
• Planificados finales: Sumatoria de los story points o relativa actuales de todos los ítems del compromiso actual del sprint o período.

No se realiza ningún cálculo adicional. Estimaciones (Story Point/Relativa): Aún referente a este indicador en el caso de las Estimaciones Story Point o Relativa es importante la siguiente aclaración: Para ambos datos se consideran los ítems que actualmente están dentro del sprint independientemente de si están en el sprint desde el inicio o fueron agregados después. Por este motivo, el primer dato no debe confundirse con la cantidad de story points o relativa que existía en el sprint cuando comenzó. Para una mayor comprensión, vea el ejemplo hipotético a continuación:

Un sprint comienza con 21 puntos con las historias siguientes: A (8), B (8) y C (5). Después de su inicio, ocurren los siguientes eventos en el orden siguiente:

• Historia D es agregada con 3 puntos.
• Historia A es modificada a 13 puntos.
• Historia D es modificada a 5 puntos.

Con esto, el indicador story points/esfuerzo planificados mostrará:

24→31

siendo:

24 = A (8) + B (8) + C (5) + D (3)

31 = A (13) + B (8) + C (5) + D (5)

Compromiso Realizado

Este indicador muestra el valor del compromiso concluido, es decir, la sumatoria de todas las estimaciones/ítems concluidos del compromiso durante el sprint o período. Este dato se recupera de la plataforma de gestión. No se realiza ningún cálculo adicional. Estimaciones/ítems:

• Estimaciones cuando se usa "Story Point" o "Relativa";
• Ítems cuando se usa "Conteo de tickets".

Nuevos Compromisos

Este indicador mide la cantidad de estimaciones/ítems* agregados dentro del compromiso

después del inicio del sprint o período. Se muestran dos datos correlacionados:

• Sumatoria de las estimaciones/ítems* agregados al compromiso después del inicio del sprint o período (Nuevos);
• Porcentaje de las estimaciones/ítems agregados al compromiso después del inicio del sprint o período en relación con el número total de las estimaciones/ítems del compromiso en el sprint o período.

Mientras el primero se recupera de la plataforma de gestión, el segundo se obtiene a través de un cálculo simple de porcentaje.

Para calcular el porcentaje necesitamos los siguientes datos – ya abordados:

• Sumatoria de las estimaciones/ítems agregados al compromiso después del inicio del sprint o período (Nuevos);
• Sumatoria de las estimaciones/ítems* actuales de todos los ítems del compromiso actual del sprint o período (Planificados Finales).

Un sprint comienza con 21 puntos con las historias siguientes: A (8), B (8) y C (5). Después de su inicio, ocurren los siguientes eventos en el orden siguiente:

• Historia D es agregada con 3 puntos.
• Historia A es modificada a 13 puntos.
• Historia D es modificada a 5 puntos.

Con esto, el indicador story points/esfuerzo planificados mostrará:

24→31

Y el indicador nuevos story points/esfuerzo mostrará:

10 (32.25%)

Siendo:

10 = (31 – 21)

32.25% = (10÷31) x 100

Variación de Estimación – Estimaciones (Story Point/Relativa)

Este indicador mide la variación de estimación de los story points/esfuerzo planificados que – recordando – son:

• Planificados iniciales: sumatoria de los story points/esfuerzo originales de todos los ítems del compromiso actual del sprint o período;
• Planificados finales: Sumatoria de los story points/esfuerzo actuales de todos los ítems del compromiso actual del sprint o período.

Con ambos datos disponibles, se calcula la diferencia (Variación) entre ellos y, a continuación, se procede con el cálculo:

(Variación÷Planificados Finales) x 100

Variación = 115 – 73

Variación = 42

Variación de Estimación = (42÷115) x 100

Variación de Estimación = 36.52

Compromiso Bloqueado

Este indicador mide la cantidad de las estimaciones/ítems actualmente bloqueados dentro del compromiso.

Se muestran dos datos correlacionados:

• Sumatoria de las estimaciones/ítems actualmente bloqueados del compromiso en el sprint o período (Bloqueados);
• Porcentaje de las estimaciones/ítems* bloqueados en relación con el número total de las estimaciones/ítems del compromiso en el sprint o período.

Mientras el primero se recupera de la plataforma de gestión, el segundo se obtiene a través de un cálculo simple de porcentaje.

Para calcular el porcentaje necesitamos los siguientes datos:

• Sumatoria de las estimaciones/ítems* actualmente bloqueados dentro del compromiso (Bloqueados);
• Sumatoria de las estimaciones/ítems* de todos los ítems cuando el sprint o período finalizó (Planificados Finales).

(Bloqueados÷Planificados Finales) x 100

Compromiso bloqueado = (3÷115) x 100

Compromiso bloqueado = 2.61

Compromiso Cancelado

Este indicador mide la cantidad de las estimaciones/ítems cancelados dentro del compromiso, es decir, la sumatoria de las estimaciones/ítems de los ítems cancelados del compromiso durante el sprint o período.

Este dato se recupera de la plataforma de gestión, pero su visibilidad depende de la configuración del VSM "Excluir issues canceladas del compromiso". La configuración proporciona dos posibilidades:

• 1 - Cuando está configurado para no considerar ítems cancelados en el compromiso, el indicador mostrará "-".
• 2 - Cuando está configurado para considerar ítems cancelados en el compromiso, el indicador mostrará la sumatoria de las estimaciones/ítems cancelados.

Aún referente a la configuración del VSM para considerar o no ítems cancelados como parte del compromiso, es importante destacar que también altera el número de las estimaciones/ítems planificados – y por consiguiente todos los indicadores que dependen de él.

Vea los ejemplos a continuación:

• 1 - No se consideran ítems cancelados y tenemos un total de 356 story points planificados.

• 2 - Cuando está configurado para considerar ítems cancelados en el compromiso, el indicador mostrará la sumatoria de las estimaciones/ítems cancelados.

Defectos del Sprint/Período

Este indicador muestra la cantidad de defectos abiertos durante el sprint/período, también conocidos como story-bugs o sub-bugs. Este dato se recupera de la plataforma de gestión y luego se presenta según la configuración del VSM de qué tipos deben tratarse como story-bug. No se realiza ningún cálculo adicional.

Sub-tareas Completadas

Este indicador muestra la cantidad de sub-tareas completadas durante el sprint o período. Este dato se recupera de la plataforma de gestión y luego se presenta según la configuración del VSM de qué tipos deben tratarse como sub-tareas. Es importante destacar que este indicador no tiene en cuenta si las sub-tareas forman parte o no del compromiso.

Demás Indicadores

Los Demás Indicadores representan indicadores complementarios de los Principales Indicadores. Algunos indicadores están presentes en ambos paneles. Este panel muestra diversa información relacionada con determinados parámetros, sirviendo como complemento en caso de que no estén incluidos en los Principales Indicadores.

Issues – Bloqueo y eficiencia

Este panel presenta de forma detallada los índices de bloqueo y eficiencia que componen la puntuación global del sprint o período analizado, proporcionando una visión clara sobre el rendimiento y las métricas relacionadas.

Porcentaje de ítems bloqueados

Este indicador mide en porcentaje cuántos ítems están actualmente bloqueados en el sprint o período. Para esto se recuperan de la plataforma de gestión dos datos:

• Número de ítems actualmente bloqueados en el sprint o período (Bloqueados);
• Número total de ítems en el sprint o período (Total);

nota

Actualmente, en el caso de sprints o períodos ya cerrados, se considera que la tarea permaneció bloqueada hasta el momento de su cierre.

Con la recuperación de ambos datos, se procede al cálculo como se presenta a continuación:

(Bloqueados÷Total) x 100

Bloqueados = (1÷26) x 100

Bloqueados = 3.85

Porcentaje que sufrieron bloqueos

Este indicador mide, en términos porcentuales, la cantidad de ítems que fueron bloqueados en algún momento durante el sprint o período en análisis.

Para esto se recuperan de la plataforma de gestión dos datos:

• Número de ítems que sufrieron bloqueos en el sprint o período (Bloqueos);
• Número total de ítems en el sprint o período (Total).

Con la recuperación de ambos datos, se procede al cálculo como se presenta a continuación:

(Bloqueos÷Total) x 100

% de Bloqueos = (3÷26) x 100

% de Bloqueos = 11.54

Porcentaje de eficiencia

Este indicador mide la eficiencia con base en el tiempo dedicado a etapas que agregan valor, en comparación con el tiempo gastado en etapas que no agregan valor.

Para esto, se recuperan de la plataforma de gestión los siguientes tres datos:

• Tiempo de todos los estados en 'WAIT';

• Tiempo de todos los estados en 'WORK' y 'WAIT';

• Tiempo en que los ítems estuvieron bloqueados en estados de 'WORK'.

Con la recuperación de los datos, se procede al cálculo como se presenta a continuación:

(100 - ((A+C)÷(B+C) x 100))÷10

A = Tiempo de todos los estados en 'WAIT'

B = Tiempo de todos los estados en 'WORK' y 'WAIT'

C = Tiempo en que los ítems estuvieron bloqueados en estados de 'WORK'

(100 - ((1756.38+309.27)÷(8092.87+309.27) x 100))÷10 = 7.39

A = 1756.38 horas (Wait)

B = 8092.87 horas (Work/Wait)

C = 309.27 horas (Bloqueo en Work)

Tiempo de bloqueos

En este panel se presentan dos indicadores relacionados con el bloqueo y la eficiencia del proceso: Tiempo Total de Bloqueo y Tiempo Promedio de Bloqueo.

• Tiempo Total de Bloqueo: Se refiere a la suma absoluta del tiempo en que los ítems estuvieron bloqueados, sin ningún tipo de cálculo adicional.
• Tiempo Promedio de Bloqueo: Calculado a partir de la división del tiempo total de bloqueo por el número de ítems bloqueados. En el ejemplo ilustrado a continuación, se consideran tres ítems bloqueados y, por lo tanto, el tiempo total de bloqueo se divide por tres, resultando en el valor promedio de bloqueo por ítem.

La imagen a continuación complementa esta explicación, ilustrando la aplicación de los indicadores mencionados.

Distribución de Tickets

Este gráfico permite tener una visión de qué tickets entraron en el sprint/período seleccionado. Permite tener una visión de tickets por clase y por tipo, además de permitir filtrar solo los tickets completados o visualizar todos.

Flujo Acumulativo de Estado

El indicador de Flujo Acumulativo de Estado o Cumulative Flow Diagram (CFD) es una herramienta visual utilizada para monitorear el progreso de un proyecto a lo largo del tiempo. Ayuda a visualizar el estado del trabajo en diferentes fases del proceso, facilitando la identificación de problemas y la optimización del flujo de trabajo. Al observar el tamaño de las áreas en el gráfico, es posible identificar dónde se acumula el trabajo. Un aumento significativo en un área indica un cuello de botella, donde las tareas están siendo retenidas y no avanzan a la siguiente fase. El área de "Completado" debe aumentar gradualmente, indicando que el equipo está entregando el trabajo según lo planificado.

Distribución del Trabajo en Progreso

El gráfico de Distribución del Trabajo en Progreso proporciona una visión clara sobre la cantidad de trabajo que está siendo asumida por el equipo en un momento determinado. Idealmente, el volumen de trabajo debe estar alineado con la capacidad de entrega del equipo, permitiendo que los integrantes se concentren en las tareas sin la necesidad de cambios frecuentes de contexto.

La recomendación es que el número de tickets en progreso sea aproximadamente equivalente al número de miembros del equipo. Cuando el volumen de tickets supera la cantidad de integrantes, existe el riesgo de que el equipo se involucre simultáneamente en múltiples tareas, lo que puede resultar en pérdida de eficiencia debido al cambio constante de foco.

Por otro lado, cuando el número de tickets en progreso es inferior al número de miembros del equipo, esto puede indicar que algunos miembros no están pudiendo actuar de forma independiente en las tareas, posiblemente debido a la falta de demandas y/o una distribución desequilibrada del trabajo.

La imagen a continuación ilustra este comportamiento y contextualiza los diferentes escenarios de distribución de trabajo.

Indicadores de flujo de trabajo

Los Indicadores de Flujo de Trabajo se utilizan para evaluar si el volumen de trabajo en progreso es adecuado para la capacidad del equipo. El objetivo es garantizar que el equipo tenga una carga de trabajo compatible con su capacidad de entrega, de forma a maximizar la eficiencia y minimizar desperdicios.

• Exceso de Trabajo en Progreso: Un número elevado de tareas simultáneamente en progreso puede indicar que el equipo está pasando mucho tiempo cambiando de contexto entre las actividades, lo que tiende a resultar en pérdida de eficiencia debido al tiempo gastado en el cambio entre las tareas.
• Insuficiencia de Trabajo en Progreso: Cuando el volumen de trabajo es bajo, puede ser un indicativo de que el equipo no tiene demanda refinada o lista para ser ejecutada en cantidad suficiente, lo que puede afectar la productividad y el ritmo de entrega.

Estos indicadores ayudan a identificar desequilibrios en el flujo de trabajo, permitiendo ajustes que promuevan una entrega más eficiente y continua.

Alertas de Uso | Calidad de los datos

Este panel muestra Alertas de Uso relacionadas con la Calidad de los Datos durante las transiciones de issues entre los diferentes estados en la herramienta de gestión. Tiene como objetivo monitorear la consistencia y la precisión de los datos, garantizando que la información registrada sea correcta a lo largo del proceso.

Las alertas identifican posibles inconsistencias o imprecisiones en la información, ayudando a garantizar que el flujo de trabajo se refleje de manera fiel en la herramienta y permitiendo acciones correctivas rápidas para mantener la integridad de los datos.

Horas por estado (en %)

Este indicador calcula la proporción de horas asociadas a cada estado en relación con el total de horas del tipo al que pertenece el estado. Los estados del tipo work son proporcionales al total de horas work, mientras que los estados del tipo wait son proporcionales al total de horas wait.

Esta métrica permite hacer seguimiento de la distribución del tiempo entre los diferentes estados del flujo de trabajo, facilitando el análisis de la eficiencia y asignación de recursos.

Estados con wait

Los estados de espera (o wait) se refieren a las situaciones en que los tickets permanecen esperando la actuación del equipo. Cuanto mayor sea el tiempo de permanencia en estos estados, menor será el indicador de eficiencia del equipo. En el gráfico a continuación, se presentan los tiempos correspondientes a cada estado. La mayor representación de un estado en el gráfico indica su contribución significativa al aumento del tiempo de entrega de las issues y, consecuentemente, a la reducción de la eficiencia del equipo.

En caso de que un estado de actuación (estado work) se muestre en el gráfico, debe incluirse en la configuración "Estado de Issues que Generan Valor (Work)", para que sea considerado como parte del trabajo efectivo, impactando positivamente en el índice de eficiencia. Por otro lado, si un estado no representa una fase de trabajo, sino una situación en que la demanda aún no está lista para ser atendida (ej.: no fue priorizada, no está en la cola), ese estado debe incluirse en la configuración "Estado de Issues que Deben Ser Excluidos del Cálculo de la Eficiencia", de modo que no se contabilice en el cálculo de la eficiencia, ya que no refleja actividades directamente relacionadas con el proceso de entrega.

Criticidad de los Defectos

El panel "Criticidad de los Defectos" presenta una visión sobre los defectos encontrados durante el desarrollo del Sprint/Período y después de la entrega.

Los Defectos del Sprint son errores detectados durante la implementación de las historias o sub-tareas dentro del Sprint, clasificados como, por ejemplo, Story Bug o Story Bug - Sub-task. Estos defectos están directamente relacionados con el proceso de desarrollo.

Los Defectos de Producción, a su vez, son fallas que surgen en el entorno de producción después de la conclusión del Sprint, siendo clasificados como Bug, por ejemplo. Estos defectos generalmente indican problemas que no fueron identificados antes de la entrega y pueden afectar la experiencia del usuario final.

La distinción entre estos tipos de defectos permite un seguimiento eficaz de la calidad durante el ciclo de desarrollo y la operación del sistema.

Causa de los Defectos

Es un complemento de la Criticidad de los Defectos, detallando las causas de los defectos del sprint o período, así como también después de las entregas.

Distribución de Lead Time

El Lead Time es el tiempo total entre la creación de una issue y su conclusión. Mide la eficiencia del proceso de entrega, indicando cuánto tiempo tarda el equipo en transformar una demanda en una entrega finalizada.

El conteo del Lead Time comienza en el momento de la creación de la issue o en otro evento configurado, como la entrada en un estado de trabajo, y termina cuando la issue se concluye. La plataforma utilizada para gestionar el flujo de trabajo puede configurarse para ajustar estos puntos de inicio y término, afectando directamente la medición del Lead Time.

Esta métrica es esencial para evaluar el rendimiento del equipo e identificar posibles cuellos de botella o áreas de mejora en el proceso de desarrollo.

El gráfico de distribución muestra cómo los valores de Lead Time están distribuidos en un determinado intervalo de tiempo. Agrupa los datos en clases o tipos y muestra la frecuencia con que estos intervalos ocurren. Esto permite visualizar el comportamiento general del Lead Time, identificando tendencias, como la mayoría de las issues siendo completadas en un tiempo más corto o más largo. Es una representación útil para comprender la forma general de la distribución de los tiempos de entrega y evaluar la consistencia del proceso.

Dispersión de Lead Time por tamaño

Como se mencionó anteriormente, el Lead Time es la métrica que mide el tiempo entre la creación y la conclusión de una issue. La principal diferencia entre los dos gráficos está en la forma en que se representan los datos. El primer gráfico muestra la distribución del Lead Time, mientras que el segundo gráfico presenta la dispersión de los datos.

El gráfico de dispersión, como su nombre lo indica, visualiza la variación individual de los valores de Lead Time a lo largo del tiempo. En lugar de mostrar una distribución agregada, presenta cada punto de dato de forma aislada, permitiendo identificar más claramente los casos que están fuera del promedio o que presentan variaciones significativas. Este tipo de gráfico es útil para analizar patrones e identificar issues que tardaron más tiempo del esperado para ser completadas.

Distribución de Queue Time

El Queue Time es el tiempo transcurrido entre el momento en que una issue entra en un estado que indica que fue priorizada o seleccionada para ser trabajada, y el momento en que se concluye. Esta métrica refleja el tiempo que la demanda permanece "en espera" o "en la cola" antes de ser efectivamente procesada, midiendo la eficiencia de la priorización y asignación de recursos.

El conteo del Queue Time comienza cuando la issue entra en un estado específico configurado, como "To Do" o "Ready for Work", o cualquier otro estado configurado como punto de inicio. Se interrumpe en cuanto la issue es finalizada o movida al estado de completada.

Al igual que el Lead Time, el Queue Time puede ajustarse según las configuraciones de la plataforma utilizada, influyendo en la forma en que se calcula el tiempo de espera. La métrica es importante para entender cuánto tiempo las issues están esperando antes de ser trabajadas, proporcionando una visión crítica de la eficiencia del proceso de priorización.

El gráfico de distribución de Queue Time presenta la variación del tiempo de espera de las issues dentro de un intervalo de tiempo determinado. Agrupa los datos en rangos de tiempo y muestra la frecuencia con que diferentes intervalos de Queue Time ocurren. Con esto, es posible visualizar la distribución del tiempo de espera, identificando patrones y posibles cuellos de botella en la fase de priorización o elección de las demandas. Este análisis ayuda a identificar si hay problemas en la agilidad de inicio de las tareas y si el proceso de asignación de recursos está funcionando de forma eficiente.

Dispersión de Queue Time por tamaño

El gráfico de dispersión de Queue Time muestra la variación individual de los tiempos de espera de las issues antes de ser iniciadas. En lugar de agrupar los datos, muestra cada punto de forma aislada, facilitando la identificación de casos con tiempos de espera muy elevados.

Este gráfico es útil para detectar patrones o situaciones atípicas, como issues que estuvieron mucho tiempo esperando para ser iniciadas. Ofrece una visión clara de la consistencia y agilidad del flujo de trabajo, ayudando a identificar áreas que pueden necesitar ajustes.

Distribución de Process Time (Touch Time)

El Process Time es la métrica que mide el tiempo entre el inicio efectivo de la actuación en la issue y su conclusión. Este tiempo refleja cuánto tarda el equipo en trabajar directamente en la demanda, desde el momento en que comienza a ser procesada hasta su entrega final.

El gráfico de distribución de Process Time muestra cómo los tiempos de trabajo están distribuidos dentro de un intervalo de tiempo específico. Agrupa los datos en clases de tiempo, permitiendo visualizar la frecuencia con que diferentes intervalos de Process Time ocurren.

Este gráfico es útil para entender el comportamiento general del tiempo de procesamiento de las issues, indicando si la mayoría de las tareas se está completando rápidamente o si hay una tendencia de demora en determinados casos. Además, permite identificar patrones en el rendimiento del equipo, como consistencia en el tiempo de ejecución o posibles variaciones en función de factores específicos.

Dispersión de Process Time por tamaño (Touch Time)

El gráfico de dispersión de Process Time muestra la variación individual de los tiempos de procesamiento de las issues a lo largo del tiempo. En lugar de agrupar los datos, muestra cada valor de Process Time de forma aislada, lo que ayuda a identificar casos con tiempos de procesamiento anormalmente largos o cortos.

Este gráfico es útil para identificar situaciones atípicas, como issues que tardaron más tiempo del esperado para ser completadas. Ayuda a visualizar casos en que el trabajo en la issue puede haber enfrentado interrupciones o retrasos, además de destacar la variabilidad en el rendimiento del equipo. El análisis de estos puntos aislados ofrece una visión detallada sobre la eficiencia del proceso de ejecución y puede indicar áreas que necesitan ajustes para mejorar la agilidad y consistencia.

Dispersión de Cycle Time por tamaño (Desarrollo)

El Cycle Time mide el tiempo que una issue permanece en la etapa de desarrollo, desde el inicio de la actuación efectiva hasta su evolución a la siguiente etapa, como la transición a pruebas, por ejemplo. Este tiempo refleja el esfuerzo necesario para avanzar la demanda en el proceso de construcción, sin considerar el tiempo de espera o la fase de conclusión.

El gráfico de distribución de Cycle Time por Tamaño muestra cómo los tiempos de desarrollo varían según el tamaño o complejidad de las issues. Agrupa los datos en intervalos de tiempo, permitiendo visualizar la frecuencia con que diferentes tamaños de issues se completan en un determinado tiempo de ciclo.

Este gráfico es útil para analizar cómo el Cycle Time se comporta en relación con el tamaño de las tareas. Puede mostrar si las issues más complejas o de mayor tamaño tardan más tiempo en ser desarrolladas o si hay una variación en el tiempo de ciclo según la complejidad. Esto ayuda al equipo a entender la relación entre el tamaño de la demanda y la eficiencia del proceso de desarrollo, permitiendo identificar áreas para mejorar la asignación de recursos o la estimación de tiempo para diferentes tipos de tareas.

Lista de Tickets

El objetivo principal de la Lista de Tickets es proporcionar un detalle completo de las issues que fueron tratadas durante el ciclo de trabajo (sprint o período específico), facilitando el análisis del rendimiento del equipo, el seguimiento de tareas y la visualización del estado actual de cada ítem. A partir de esta lista, es posible obtener una visión detallada del progreso de cada ticket, identificar posibles bloqueos, verificar el historial de cambios de estado y otros detalles asociados a su ejecución.

Funcionamiento del Panel

La Lista de Tickets incluye diversa información relevante sobre las issues del período o sprint, tales como:

• ID del Ticket: Muestra el identificador único de la issue. Al hacer clic en el ID, el usuario es redirigido a la herramienta de origen (plataforma de gestión de las issues) para ver más detalles o realizar acciones adicionales.
• Estado de la Issue: Indica el estado actual de cada issue, mostrando dónde se encuentra en el flujo de trabajo (por ejemplo, "En desarrollo", "En prueba", "Homologación", "Completado", etc.).
• Tiempo Gastado en Cada Estado: Muestra el tiempo total que cada issue permaneció en cada estado durante el período del sprint, ayudando a identificar posibles cuellos de botella en el flujo de trabajo.
• Responsable: En la plataforma de gestión de issues, se indica qué miembro del equipo es responsable de cada tarea. Esta información facilita el seguimiento de la carga de trabajo individual y el análisis de la distribución de las actividades.
• Fecha de Creación y Conclusión: Muestra las fechas de creación y conclusión de cada ticket, permitiendo un análisis más profundo sobre el tiempo de ejecución de cada tarea y la eficiencia en el ciclo de vida del ticket.
• Tipo de Issue: Puede ser un bug, mejora, tarea técnica, entre otros, facilitando la categorización y el análisis de tipos específicos de demandas dentro del sprint.

Filtro de búsqueda

La Lista de Tickets ofrece la posibilidad de utilizar filtros para refinar la búsqueda y localizar rápidamente información específica. Estos filtros pueden aplicarse con base en varios criterios, como:

• Filtro por Estado: Filtra por estado específico para ver solo tickets en determinadas etapas del proceso.
• Filtro por Indicador: Filtra por indicadores de las issues, como "abierto", "cancelado", "completadas" entre otros.
• Filtro de texto: Filtra las issues con base en el texto escrito en el filtro.

Cómo usar

• Al visualizar la Lista de Tickets, utilice los filtros disponibles para refinar su búsqueda según la necesidad.
• Haga clic en el ID del Ticket para ser redirigido a la herramienta de origen, donde puede visualizar más información.
• Use la lista para monitorear el progreso de cada ticket e identificar áreas que puedan requerir atención, como tickets que están tardando más tiempo del esperado para ser finalizados o que están bloqueados en un estado específico.

Beneficios

• Visibilidad y Control: Ofrece una visión clara y detallada de todas las issues trabajadas durante el período o sprint, permitiendo que los gestores hagan seguimiento del avance de las actividades en tiempo real.
• Análisis de Rendimiento: A través de la información sobre tiempo gastado en cada estado y los responsables, es posible identificar potenciales áreas de mejora, como cuellos de botella en el flujo de trabajo o desequilibrios en la distribución de tareas.
• Facilidad de Seguimiento: Con la capacidad de filtrar y buscar issues específicas, la lista se convierte en una herramienta práctica para el seguimiento y gestión del progreso del equipo, sin sobrecarga de información.

Totalización de las transiciones por estado

Presenta una visión detallada de las transiciones de estado de las issues a lo largo del flujo de trabajo, proporcionando información sobre el tiempo gastado en cada etapa y el rendimiento del equipo. Incluye varias métricas que ayudan a monitorear y analizar la eficiencia del proceso, identificar cuellos de botella y evaluar el impacto del retrabajo en las entregas. A continuación están los principales componentes del panel:

• En trabajo/Agregando Valor (horas): Esta métrica contabiliza la cantidad de horas que las issues están en estados de trabajo, es decir, cuando el equipo está efectivamente realizando actividades de desarrollo, como codificación o pruebas. Este tiempo se considera como "agregando valor", ya que representa el período en que el equipo está activamente contribuyendo al progreso de la entrega.
• En espera/Desperdicio (horas): Aquí se contabilizan las horas que las issues permanecen en estados de espera, como "esperando deploy" o "en espera". Estos estados se consideran como desperdicio, ya que representan períodos en que la issue no está siendo activamente trabajada. El objetivo es reducir este tiempo, ya que, sin estas esperas, el tiempo total de entrega sería menor.
• Esfuerzo (worklog): Se refiere a las horas que el equipo registra en la plataforma de gestión de issues, específicamente en el campo de worklog, como el tiempo efectivamente dedicado al trabajo en las issues. Estas horas representan el esfuerzo del equipo en el desarrollo de las actividades, siendo una métrica importante para medir la carga de trabajo y el compromiso del equipo.
• Total de ocurrencias: Este indicador muestra el número total de issues que pasaron por determinado estado a lo largo del período analizado. Permite verificar la frecuencia con que las issues transitaron por ese estado, ayudando a identificar qué fases del proceso tienen mayor volumen de transiciones.
• Repetición - Ticket volvió a pasar por el estado: Se refiere a las issues que regresaron a un estado previamente alcanzado. Por ejemplo, una issue que fue a "En Prueba" y luego volvió a "Desarrollo" para ajustes, y luego regresó a "En Prueba". La métrica de repetición ayuda a identificar posibles retrabajos o ciclos de validación que pueden indicar ineficiencias o falta de claridad en los requisitos.
• Porcentaje de tickets completos (sin retrabajo): Este indicador presenta el total de issues que pasaron por determinado estado y el porcentaje de ellas que no sufrieron retrabajo. Es decir, muestra la proporción de issues que transitaron por el estado de forma lineal, sin necesidad de regresar a fases anteriores. Este porcentaje es importante para evaluar la calidad del trabajo realizado y la eficiencia del flujo de entrega, ya que un porcentaje bajo de tickets completos puede indicar problemas con la calidad o con los procesos de revisión y validación.

Distribución de tickets en el backlog del equipo

El indicador de Distribución de Tickets en el Backlog del Equipo es una métrica esencial para monitorear la organización y priorización de las tareas y solicitudes dentro del backlog. Ofrece una visión clara sobre la asignación y el equilibrio de las demandas, permitiendo identificar patrones y posibles cuellos de botella en el proceso de gestión del trabajo. El análisis de este indicador proporciona información valiosa para la toma de decisiones estratégicas, permitiendo una mejor comprensión de la carga de trabajo del equipo y la eficiencia en el flujo de tareas. Además, contribuye a la optimización del proceso de priorización, asegurando que los ítems más relevantes sean atendidos dentro de los plazos estipulados.

Distribución del tiempo de las issues en backlog

El indicador Distribución del Tiempo de las Issues en Backlog mide el tiempo transcurrido entre la creación de una issue y el inicio del Sprint/Período en que es efectivamente trabajada. El cálculo se realiza desde la fecha de creación de la issue hasta la fecha de inicio del Sprint/Período, siendo esta última utilizada como referencia para identificar el momento en que los ítems fueron seleccionados del backlog del producto y movidos al backlog del Sprint/Período. Este indicador es fundamental para analizar el tiempo que las issues permanecen en el backlog antes de ser priorizadas e incluidas en un Sprint/Período, ofreciendo perspectivas valiosas sobre el proceso de selección y planificación. Además, el análisis de este dato puede revelar posibles cuellos de botella en la preparación del trabajo, ayudando al equipo a mejorar la previsibilidad y la eficiencia en el ciclo de desarrollo.

Análisis del backlog

Este indicador varía de 0 a 10 y tiene como objetivo medir la salud del backlog del producto y del sprint/período en relación con los defectos de producción (bugs).

Si un equipo hipotético tiene muchos defectos en el backlog del producto, genera una cantidad significativa de defectos durante un sprint o período, y no consigue corregir los defectos de manera sostenible, el score de ese equipo será bajo.

Por otro lado, si el equipo tiene pocos defectos en el backlog del producto, genera pocos defectos durante un sprint o período, y consigue corregir más defectos de los que genera, el score será alto.

Sobre este score, es importante notar que existen dos variaciones de cálculo: la estándar y la ponderada. La variación a utilizar depende de cómo el indicador fue parametrizado en el registro de la organización en Agile Cockpit.

Para consultar qué variación está en uso actualmente, acceda al modal de detalles y verifique si el mensaje mostrado es:

Cálculo estándar:

Este cálculo determina cuántos Sprints/Períodos son necesarios para limpiar el backlog de defectos, utilizando la fórmula:

Sprints/Períodos = (Antiguos + Nuevos)÷(Nuevos - En corrección)

Ejemplo:

Con Antiguos = 0, Nuevos = 2 y En Corrección = 3:

Sprints/Períodos = (0 + 2)÷(2 – 3) = -2

Cálculo del Score:

Si Sprints/Períodos < 0 o > 12, el score es 0, Si Sprints/Períodos < 2, el score es 10.

Para otros casos, el score se calcula como:

Score = 10 - (Sprints/Períodos - 2)

Ejemplo de Score:

Si Sprints/Períodos = 2: Score = 10 - (2 – 2) = 10

Cálculo ponderado:

El sistema asigna pesos diferentes a los defectos, con base en su situación actual y criticidad:

• Situación: La lista de situaciones es fija (tres) y cada situación es un indicador separado.
• Criticidad: La lista de criticidades es dinámica y parametrizable en el registro de la organización.

Recuperación de Datos:

• De la herramienta de gestión: Cantidad total de defectos y defectos por criticidad.
• Del registro de la organización: Pesos de criticidades e indicadores.

Ejemplo: Cantidad Ponderada:

Ctd. Ponderada = Í (Ctd.×Peso C)

Total Ponderado:

Total Ponderado = Ctd. Ponderada x Peso I

Con los indicadores ponderados calculados, el score final se determina a partir del campo total de cada indicador. Para el cálculo estándar, se usa el total de cada indicador, mientras que en el cálculo ponderado, se utiliza el total ponderado.

Pesos:

• Los pesos de las situaciones y criticidades son parametrizables, con valores predeterminados sugeridos por el sistema.
• Si una criticidad no está parametrizada, su peso será 1.
• Para el cálculo estándar, todos los pesos son iguales a 1.

Indicadores:

• En backlog fuera del sprint/período: Defectos creados antes del sprint, fuera del backlog del sprint.
• Creados durante el sprint/período y fuera del sprint/período: Defectos creados durante el sprint/período, pero fuera del backlog del sprint.
• En corrección en el sprint/período: Defectos que están en el backlog del sprint/período.

Ejemplo de Cálculo Ponderado: Si tenemos:

Antiguos = 192

Nuevos = 0

En Corrección = 272

El total sería:

Total = 192 + 0 + 272 = 464

Y el cálculo del score ponderado sería:

Fórmula = (En corrección Total÷Total) x 2 x 10

Score = (272÷464) x 2 x 10 = 10

Burndown de issues

El gráfico de burndown es una representación visual del trabajo restante versus el tiempo disponible, siendo utilizado para monitorear el progreso del equipo a lo largo de un Sprint/período.

La línea de trabajo abierto "ideal" indica la cantidad de trabajo que debería permanecer pendiente en cada momento, con el fin de garantizar que todo el trabajo planificado sea completado al final del Sprint/período.

Por otro lado, la línea de trabajo abierto "alcanzado" representa la cantidad real de trabajo que permanece abierto hasta el momento.

Cuando la línea de alcanzado se encuentra por encima de la línea ideal, esto indica que el equipo está "atrasado" en relación con la meta establecida. En ese caso, deben tomarse acciones correctivas para recuperar el tiempo perdido, buscando aproximar la línea de alcanzado a la línea ideal.

Si la línea de alcanzado está por debajo de la línea ideal, significa que el equipo está "adelantado" en relación con la planificación. En ese escenario, deben tomarse medidas para evitar que el equipo quede inactivo hasta el final del Sprint/período, garantizando la continuidad del trabajo y la optimización del tiempo.

Burnup de issues

El gráfico Burnup ofrece una representación visual del trabajo completado en un Sprint/período, comparándolo con el alcance total planificado. Permite hacer seguimiento del progreso del equipo hacia la conclusión del Sprint/período e identificar posibles problemas relacionados con el aumento del alcance durante el ciclo.

El eje vertical del gráfico representa el total de trabajo para el Sprint/período, generalmente medido en número de tareas o puntos. El eje horizontal, a su vez, refleja el paso del tiempo a lo largo del Sprint/período, normalmente en días. La línea diagonal gris, que atraviesa el gráfico, representa el progreso ideal de conclusión del trabajo a lo largo del tiempo. La línea azul indica la conclusión real del trabajo, mientras que la línea verde refleja la cantidad de issues aún abiertas.

A medida que el trabajo se completa, la línea azul debe seguir de cerca la línea diagonal (progreso ideal), garantizando que el objetivo del Sprint/período sea alcanzado al final. Además, la línea verde debe disminuir progresivamente, indicando que el número de issues pendientes está siendo reducido a lo largo del tiempo.

Proporción por tamaño

Este gráfico muestra la distribución de las issues en el Sprint según su tamaño relativo, permitiendo visualizar la proporción de trabajo asociado a diferentes categorías de tamaño de las tareas.

Si la opción "Completadas" es seleccionada, el gráfico considerará solo las issues que están en el estado de completadas en la configuración, es decir, aquellas que ya fueron completadas y entregadas según los parámetros del equipo/organización. Esta funcionalidad permite hacer seguimiento específicamente del progreso de las issues finalizadas dentro del Sprint, facilitando el análisis del trabajo completado en relación con su tamaño.

Distribución de Lead Time hasta homologación

El Lead Time hasta Homologación es el tiempo total entre la creación de una issue y su conclusión, es decir, hasta la homologación, cuando la issue alcanza el estado de "completado" u "homologado". Esta métrica mide la eficiencia del proceso de entrega, indicando cuánto tiempo tarda el equipo en transformar una demanda en una entrega lista para ser validada.

El conteo del Lead Time hasta Homologación comienza en el momento de la creación de la issue o de otro evento configurado, como la entrada en un estado de trabajo, y termina cuando la issue llega al estado de Homologación, considerado el punto final del proceso de entrega. La plataforma utilizada para gestionar el flujo de trabajo puede configurarse para ajustar estos puntos de inicio y término, lo que impacta directamente la medición del Lead Time.

Esta métrica es fundamental para evaluar el rendimiento del equipo e identificar posibles cuellos de botella o áreas de mejora en el proceso de desarrollo hasta el momento de la homologación, antes de que la issue sea efectivamente entregada al cliente o parte interesada.

Motivos de impedimentos y bloqueos

La Métrica de Bloqueos se utiliza para rastrear y categorizar los principales motivos que causan la paralización o retraso en el avance de las actividades. El objetivo de esta métrica es identificar y comprender los factores que impiden el progreso del trabajo planificado, ofreciendo perspectivas valiosas para la mejora continua del proceso y para la eliminación o mitigación de obstáculos en el flujo de trabajo.

El impacto de los bloqueos es directo en el tiempo de entrega del proyecto: cuanto más frecuentes y prolongados sean los bloqueos, mayor será el tiempo necesario para completar las actividades. Por lo tanto, monitorear esta métrica es esencial para aumentar la eficiencia del equipo, promoviendo un entorno de trabajo más productivo y menos sujeto a interrupciones. Con esto, el equipo se vuelve más autónomo y capaz de lidiar con posibles obstáculos, mejorando el flujo de trabajo y reduciendo los impactos negativos en el cronograma.

Pestaña Comparativo - Indicadores de Comparativo

Insight Metrics

Este modal fue desarrollado para ayudar al usuario a identificar déficits en las entregas. Proporciona una comparación entre los datos de más de un Sprint o Período, eliminando la necesidad de alternar entre pestañas para acceder a la información. Utilizando inteligencia artificial, la herramienta ofrece una visión clara de lo que está mejorando o empeorando en el equipo. Estos indicadores ayudan a identificar puntos críticos que necesitan ser abordados, permitiendo que el equipo mejore su rendimiento en situaciones futuras. Además de mostrar una comparación entre los Sprints/Períodos seleccionados, proporcionando transparencia y un mayor control de la evolución del equipo.

Después de cargar más de un sprint/período, es posible iniciar el análisis.

En la imagen es posible observar que los Sprints/Períodos están siendo procesados por la inteligencia artificial. Este procesamiento permite realizar un comparativo e identificar las mejoras y los déficits de rendimiento del equipo. Dentro de los Insights con IA, se abordan los siguientes puntos:

Work y Wait:

Este insight presenta una métrica que permite evaluar el tiempo de progreso en comparación con el tiempo de ociosidad. Analizamos el tiempo de actuación en Sprints/Períodos cargados previamente, como se ilustra en la imagen a continuación, que revela el porcentaje de mejora o empeoramiento durante ese intervalo. Este análisis nos ayuda a entender mejor la eficiencia y la productividad a lo largo del tiempo.

Throughput:

En este insight, se analiza la eficiencia de las entregas utilizando el Throughput, que mide la cantidad de ítems completados en cada período. Al comparar la cantidad de tareas finalizadas en diferentes intervalos de tiempo, conseguimos calcular un promedio de entregas por iteración. Estos datos se evalúan con la ayuda de inteligencia artificial, permitiendo un comparativo entre los períodos presentados en la imagen a continuación. Este enfoque proporciona una visión detallada sobre el ritmo de producción, destacando la evolución y la consistencia de las entregas a lo largo del tiempo.

Process Time:

En este insight, realizamos una comparación de la eficiencia en las entregas, utilizando la diferencia entre el tiempo inicial y el tiempo final. Con esto, calculamos el promedio del tiempo de todas las tareas completadas. Estos datos serán analizados mediante inteligencia artificial, permitiendo un comparativo entre los períodos presentados en la imagen a continuación. Este enfoque nos proporciona una visión más clara sobre el rendimiento y la evolución en las entregas.

Lead Time:

En este insight, se realiza un análisis comparativo del tiempo transcurrido entre la entrada de un ítem en las etapas de upstream y su término en entorno productivo en las etapas de downstream.

nota

• Upstream: Se refiere al conjunto de etapas que ocurren antes del inicio de las actividades productivas.
• Downstream: Abarca las etapas de desarrollo, ejecución y/o producción de los ítems.

Este análisis nos permite identificar oportunidades de mejora y optimización en el flujo de trabajo.

Comparativo de los Sprints/Períodos

Esta tabla trae 5 indicadores: Diferencia estimada vs Realizada, % no entregado, Entrega estimada, Entrega realizada y % total entregado. El objetivo, como su nombre lo indica, es traer un comparativo de estos resultados entre los sprints/períodos abiertos sin necesidad de cambiar de pestaña.

Compromiso Entregado

El compromiso entregado representa el total de story points o cantidad de issues entregadas en cada Sprint/Período. Las configuraciones pueden variar entre story points, conteo de tickets o relativa. Al cambiar estas configuraciones del cálculo pueden dejar esta visión distorsionada hasta que pasen algunos Sprints y ocurra la estabilización. Es importante que estos datos tengan en cuenta el porcentaje del compromiso entregado para tener una mejor lectura de la evolución.

Evolución Score

Este gráfico tiene el objetivo de proporcionar una mejor visión de la evolución de la puntuación, impedimentos, backlog de defectos, eficiencia a través del tiempo y compromiso.

Evolución del Backlog de Defectos

Este trae una evolución de los bugs. Es posible observar, mediante este indicador, si la entrada y la salida de defectos están ocurriendo en la misma proporción. Presenta tres métricas principales: Defectos en el Backlog, Defectos Incluidos en el Sprint y Defectos Creados durante el Sprint, ofreciendo una visión amplia de la evolución de los defectos a lo largo del tiempo.

Evolutivo

En este gráfico es posible verificar diversos factores como Cantidad total de issues del backlog, Defectos del Sprint Abiertos e Issues completadas. Además, se puede hacer seguimiento de la evolución entre el porcentaje de compromiso entregado y el porcentaje de retrabajo (porcentaje de story bugs por historia de usuario).

Equipos de los Sprints/Períodos y Compromisos Realizados

Este gráfico permite ver la relación entre los equipos y los story points entregados dentro de los Sprints o Períodos.

Distribución de Tickets

Este gráfico utiliza colores para ilustrar la cantidad y los tipos de issues insertados en cada Sprint o período, permitiendo un análisis claro del trabajo realizado y de su volumen.

Comparativo de Tipos de Defecto

Es importante tener un control de los bugs y este gráfico brinda una buena visión de los bugs creados durante cada sprint/período.

Criticidad de los Defectos

Este gráfico permite una mejor visión de la criticidad de los bugs incluidos en cada sprint/período. Muestra barras, agregando un color a cada sprint/período seleccionado y separa por criticidad en el eje x. Estos valores de criticidad dependen del utilizado por el cliente en su plataforma de gestión.

Work (+)/ Wait (-)

Este gráfico muestra una visión de cuánto tiempo las issues pasaron por cada estado y puede verse en conteo de horas o en porcentaje. Los valores de los estados de Wait se contabilizan como negativos y se muestran debajo del eje X, mientras que los valores de Work son positivos y se muestran encima del eje X.

Eficiencia de Detección de Defectos

Este gráfico muestra cuántos defectos (Story Bugs) fueron encontrados en cada sprint/período.

Compromiso: Estimado vs Realizado

Este gráfico de barras muestra la cantidad de story points estimados y realizados en cada sprint o período. Los resultados se diferencian por colores, facilitando la interpretación y análisis de los datos.

% Entregado vs % No Entregado

Similar al gráfico de Compromiso entregado vs Realizado, este gráfico muestra los datos de porcentaje de story points entregados versus el porcentaje de story points no entregados en cada sprint/período. Los datos se muestran en colores diferentes para una mejor visualización.

Compromiso, Tasks y Defectos

Este gráfico permite hacer seguimiento de la evolución y tener un comparativo entre los sprints/períodos seleccionados teniendo en cuenta 4 indicadores: Tickets estimados, Tickets completados, tasks completadas y defectos.

nota

Este gráfico tendrá en cuenta la configuración realizada en el compromiso actual estimado en el caso de Story Point, Relativa o en el caso de conteo de tickets informa los ítems que entraron en el compromiso.

Motivo de Impedimentos y Bloqueos

Este gráfico muestra los motivos de las creaciones de los defectos (story bugs) dentro de los sprints/períodos y cuántos fueron creados por el mismo motivo.

Throughput

Este gráfico fue agregado para que los usuarios puedan comparar la cantidad de tareas entregadas en cada intervalo de tiempo (Sprint o Período). La información puede visualizarse por clase o por tipo, facilitando el análisis de las entregas.

Este gráfico presenta un detalle que muestra el promedio de entregas para cada tipo de issue, además de un resumen absoluto para cada período comparado, agrupados por los meses en que hubo interacción. También calcula el promedio de los valores representados en la imagen anterior, con el objetivo de demostrar de forma más clara qué tipos de tareas estamos abordando para mejorar las entregas.

Además, es posible detallar los tipos de issues, permitiendo visualizar la cantidad total de ítems comprometidos en comparación con la cantidad de ítems entregados, todos agrupados por mes. Este análisis proporciona una comprensión más clara del rendimiento del equipo, ayudando a identificar áreas de mejora y la eficiencia en las entregas. Con esta información, los usuarios pueden ajustar sus estrategias y enfocarse en las issues que necesitan atención especial, optimizando así el flujo de trabajo y la productividad.