Métricas ágiles para equipos y proyectos

¡Comparte!

Hace algunas semanas sostenía una video conferencia con alguien sobre la gestión de equipos multidisciplinarios y distribuidos a gran escala. Unos años atrás acuñé el término «agilidad para adultos» como título para una conferencia. Este término representa el hecho de que la gestión de pequeños equipos y modelos para motivar e inspirar, la gran escala requiere además modelos más avanzados de métricas ágiles.

Más allá de los papelitos autoadhesivos (conocidos como la popular marca de 3M post-it) y las frases aspiracionales que suenan bonito para motivar a los equipos, el reto de la agilidad pensada para lograr cosas a gran escala está en movilizar una mayor estructura organizacional.

Grandes metas, grandes retos

Completar iniciativas o alcanzar metas de un orden de magnitud superior no es tarea simple. Y siempre que pensamos en este problema surgen las siguientes preguntas: ¿cómo construimos indicadores y métricas ágiles para monitorear la operación? ¿métricas ágiles que de verdad permitan ver qué tan buenos somos o qué tan bien vamos en nuestros proyectos? ¿qué métricas ágiles nos permiten tomar decisiones mejor informadas?

No obstante, y para fines de este artículo, quiero aclarar que soy un enamorado de la codificación o el desarrollo de software – coding. La vida profesional me llevó por los caminos de la gestión de equipos y proyectos, pero nunca he dejado de «echar» código. Nunca por más de un año. A veces lo hago por hobby. Con regularidad tomo cursos en alguna plataforma online para mantenerme un poco actualizado o apoyo proyectos de desarrollo tirando algunas líneas de código. Desde el poco valorado PHP hasta poderoso Go.

El código es algo que me apasiona. Gracias a esta conjunción entre gestionar personas y escribir letricas de colores ^[1] En los editores de código fuente más populares se acostumbra a tener una funcionalidad llamada syntax highlighting que resalta las palabras, instrucciones clave y símbolos, haciendo más simple diferenciar el código y su estructura. he tenido la suerte de participar, coordinar y liderar proyectos con pocas, muchas o cientos de personas, entre diseño, desarrollo, pruebas y operación. Y desde esa perspectiva comparto las métricas ágiles que he usado o uso en mis proyectos y con mis equipos.

Este artículo contiene un resumen de las métricas, los indicadores y los tableros de control – dashboard – que he trabajo con éxito a lo largo de los años y que hoy, en mi rol de consultor, me gusta implementar con los equipos para los que sirvo.

Medidas, métricas e indicadores

Por mucho tiempo pensé que medida, métrica e indicador eran esencialmente lo mismo. Con el tiempo encontré diferencias sutiles y con la experiencia comprendí la gran distancia que hay entre ellas.

Así que, ¿cuál es la diferencia entre medidas, métricas e indicadores? Vamos con algunas definiciones y un ejemplo de los buenos.

	Definición	Ejemplo
Medida o medición	Es el resultado de la comparación de una cantidad (lo que queremos medir) y un valor de referencia constante o estándar (metros, bytes, kilogramos).	10 requerimientos 5 defectos de baja prioridad 3 entregas 4 iteraciones
Métrica	Es la combinación de dos o más mediciones para ofrecer proporciones o relaciones.	100 kilómetros por hora 50 gigabytes por segundo 30 puntos de historia por iteración
Indicador	Es un valor de calificación o valoración que, frente a un resultado, nos dice algo.	100% de cumplimiento 3% de rendimiento A+ en un examen

Ejemplo comparativo entre medida, métrica e indicador

Para entender la diferencia en un ejemplo donde usamos medidas, métricas e indicadores, me gustaría exponer el siguiente ejemplo.

Joanna rindió una prueba de 100 preguntas y obtuvo 50 correctas.

Valoración subjetiva de los datos

En su opinión, ¿cómo cree que le fue a Joanna? Veamos.

• Joanna rindió una prueba de 100 preguntas (medición)
• De acuerdo con los creadores de la prueba, Joanna respondió 50 preguntas de manera correcta (medición). Esta medición resulta de comparar cada pregunta y su respuesta con la pregunta y respuesta esperada (estándar).
• Joanna obtuvo el 50% de las preguntas correctas (métrica). Esta métrica es la relación entre las preguntas totales y las preguntas correctas.

Experiencias y juicios de valor

En este punto seguramente dirás: «Joanna ha reprobado«. La verdad es que estás usando una métrica como un indicador. Esto sucede al suponer que el objetivo de la prueba era obtener el 100% de las respuestas correctas. Esto puede ser correcto en la escuela y la universidad, pero en el contexto empresarial son solo juicios de valor – opiniones muy subjetivas.

Para definir o identificar un indicador, agreguemos un poco más de información al ejemplo.

Luego de evaluar más de 15.000 pruebas realizadas al mismo número de personas, descubrimos que Joanna obtuvo uno de los puntajes más altos, superando a más del 99% de los evaluados.

¡Momento que soy lento! Se puso interesante. A pesar de responder solo el 50% de las preguntas correctamente, Joanna está dentro del 1% que obtuvo el mejor puntaje. ¿Qué opinas ahora? ¿Tienes algún indicio sobre Joanna y su desempeño? ¿Sientes que ese 99% te dice algo? ¿Podrías ofrecer una opinión más objetiva de Joanna y su prueba?

Desde luego que sí. El 99% nos dice que Joanna es una de los 150 mejores entre 15.000. Y desde luego, podemos asegurar que Joanna es de las buenas – o de las menos malas, si te pones algo exigente con el hecho de que solo respondió correctamente el 50%. En ambos casos, ese número (99%) es un indicador. Si el 50% era una métrica fría que bajo algunos prejuicios o paradigmas se asumía como un indicador, 99% si nos dice algo y reduce la objetividad de nuestro juicio.

¿Cómo definir correctamente indicadores y métricas ágiles?

Ahora que está clara la diferencia entre medición, métrica e indicador, entro en materia para traer ejemplos de indicadores y métricas para la agilidad. Sin embargo, no es posible definir métricas e indicadores que apliquen a cada contexto. Para mantener el artículo ameno y simple, voy a establecer dos objetivos diferentes:

1. Medir el desempeño de un equipo ágil con indicadores y métricas
2. Medir el desempeño de un proyecto y su progreso a terminación

Aunque muchas de las mediciones son las mismas, las métricas e indicadores buscan establecer relaciones e indicios diferentes. No debes olvidar la temporalidad de los proyectos, es decir que desde su concepción tienen un principio y un final.

Vamos con un ejemplo, si tienes a tu cargo el área de TI de una organización, en condiciones normales, no estarías pensando en desarmar el equipo de manera arbitraria. Sin embargo, cuando hablamos de proyectos inevitablemente pensamos en un equipo que, con absoluta certeza, ha de desintegrarse – adjourning dirían los entendidos.

¿Qué son los Puntos de Historia o Story Points?

Este es un artículo habla sobre métricas ágiles. Un concepto que debo aclarar antes de avanzar es el de Puntos de Historia – Story Points o SP. Sin embargo, eso no quiere decir que estoy hablando exclusivamente de Scrum. Para entender cómo funcionan las métricas de equipos ágiles debemos definir el contexto y determinar:

1. Un periodo de medición, como los Sprints en Scrum, las iteraciones – en término genérico para todos los modelos ágiles e híbridos, o los Incrementos de Programa en SAFe.
2. Definir una unidad de medida del esfuerzo – qué ojalá incluya de alguna manera la complejidad y el riesgo. Imagine tener que consolidar un tablero de múltiples equipos con horas/persona, puntos de función y SP, ¡una verdadera locura!

Lo primero es simple, definir un periodo de tiempo fijo – una semana, una iteración, un mes, un trimestre o un año. Lo segundo requiere de una discusión más profunda. Las unidades de medida más comunes que usamos para medir el esfuerzo sin:

1. Horas persona – cuántas horas durará la realización de una tarea o el completar un entregable.
2. Días ideales persona – cuántos días ideales, es decir, sin interrupciones o cambios de tarea le tomaría alguien completar una tarea o entregable. Los días ideales casi siempre se acompañan de un factor de productividad. Es decir, 3 días ideales con un factor del 50% significa que tomará 6 días completarlo.
3. Puntos de función – difícil de explicar si no se dedica a la programación, pero dejo un enlace para los curiosos.
4. Puntos de Historia

¿Pero, qué son en realidad los Puntos de Historia o Story Points? En seguida te explico con un ejemplo simple.

Definición de Puntos de Historia

Los puntos de historia – Story Points o SP – son una unidad de medida para expresar una estimación relativa de esfuerzo. Esta estimación contempla en un solo valor:

• Esfuerzo
• Complejidad
• Riesgo

Para entender el concepto te dejo un ejemplo.

Una persona debe instalar 20 ventanas en un edificio de 10 pisos. Todas iguales, de las mismas dimensiones y ancladas con los mismos mecanismos. El edificio no tiene modificaciones estructurales que impliquen cambios en el proceso de instalación.

Una persona dedicada a organizar el cronograma de trabajo podría asumir que, si instalar una ventana toma entre 20 y 30 minutos, el proceso total de instalación de las 20 ventanas toma entre 400 y 600 minutos.

Sin embargo, si consideramos que no todas las ventanas están en el mismo piso y que existe un riesgo adicional por la altura, podríamos asumir que: ^[2] El ejemplo de las ventanas, desde luego esta simplificado en exceso para resaltar el hecho de que la duración de una actividad no es la única variable considerada dentro del cálculo de SP. :

• Las ventanas de los primeros 3 pisos tienen un puntaje relativo de 1_SP
• Las ventanas de los pisos 4 a 8 tienen un puntaje relativo de 2_SP – mayor riesgo y complejidad
• Y las ventanas de los pisos 9 y 10 tienen un puntaje relativo de 3_SP – mucho mayor riesgo y complejidad

Como ven, los SP consideran que, a mayor altura tenemos mayor complejidad o riesgo. No solo evaluamos la duración en tiempo de las actividades, también consideramos otras dimensiones como el riesgo o la complejidad.

Los Story Points son una unidad de medida relativa que solo hace sentido cuando tienes más de una solicitud o requerimiento para analizar. Establecer de forma independiente que un requerimiento ABC pesa o equivale a 3_SP, 5_SP o 20_SP no tiene ningún sentido. Sin embargo, decir que la solicitud ABC es 3_SP y que la XYZ es 5_SP, nos dice que XYZ contempla casi el doble de esfuerzo, complejidad y riesgo que ABC.

Métricas para un equipo ágil

Más allá de los proyectos, existe un universo de gestión donde podemos considerar el trabajo como continuo e indefinido. Lo sé, nadie vive para siempre y en nuestros tiempos, muchas personas no duran ni dos años en sus puestos de trabajo. Sin embargo, la forma como entendemos el desempeño de un equipo es de forma continua.

¿Qué métricas son útiles en un equipo? Acá vamos con las más comunes

Capacidad: ¿qué tanto creemos que podemos completar?

La definición que más me gusta de capacidad – capacity – es: la cantidad de trabajo que consideramos o proyectamos que podemos completar en un periodo definido de tiempo.

La capacidad se mide (medición) en horas por persona, puntos funcionales o puntos de historia. No siempre contamos con la información para fijar la medición en una unidad particular, y parte del trabajo de un Scrum Master o un facilitador en roles como RTE, DASSM, será validar que la métrica definida y la medición favorecen el contexto de la organización y no son un «dolor de cabeza» en lugar de un «alivio» ^[3]En el mundo ágil, se favorece la estimación relativa. Dentro de las prácticas más populares de estimación relativa se encuentra el Póquer de Planificación – Planning Poker. Así mismo, la unidad más utilizada son los puntos de historia, pero no por eso son la única opción.

Velocidad: ¿Cuál es la capacidad y cuánto hemos completado?

La velocidad es un concepto asociado a la cantidad de trabajo que un equipo puede realizar o completar en un periodo. Fue originalmente diseñada para medir la «productividad individual» en los equipos en eXtreme Programming (XP) – cosa que no hizo muy feliz a algunas personas. Originalmente se usaba la velocidad –velocity– para determinar el «factor de carga» de un equipo. El factor de carga era un concepto enredado que fue desplazado por los Puntos de Historia.

Hoy en día, la Velocidad es una cantidad de puntos – de esfuerzo relativo, como los SP – en un periodo dado. Los podemos clasificar en:

• Velocidad Planeada: Cantidad de puntos que un equipo espera completar en un periodo.
• Velocidad Real: Cantidad de puntos que un equipo completó efectivamente en un periodo – Cabe anotar que, en Scrum, «completar» incluye el trabajo del Equipo de Desarrollo y la aprobación del PO – es decir, completado y aprobado.

Cumplimiento: ¿qué hemos completo con éxito?

Cumplimiento podemos definirlo como la cantidad (medición) de trabajo que fue efectivamente entregado o resuelto dentro de un periodo de tiempo definido (otra medición). No obstante, en contextos de alta variabilidad, me gusta separar o descomponer esta medición en dos:

1. Cumplimiento sobre el plan: ¿qué de lo que planeamos hacer pudimos completar con éxito?
2. Cumplimiento sobre el esfuerzo: ¿qué tanto de lo que creemos que podíamos completar fue completado?

Aunque a simple vista podrías considerar que son lo mismo. Y de seguro algún Scrum-maniac considerará que dentro de un Sprint no podemos incluir trabajo adicional. No obstante, no siempre es así^[4]El término Scrum-maniac se relaciona con el amor ciego y que desconoce las realidades sobre un modelo académico de gestión. Me sorprende lo políticamente correcto de mi definición. .

Si el periodo de tiempo lo permite, o el alcance del trabajo – scope – es extremadamente variable, es muy probable que encontremos nuevos elementos o incluso intercambiemos algunos – que consideramos de magnitud similar. En este contexto, las tareas planeadas al inicio del periodo no son necesariamente una buena métrica para el cumplimiento.

Variabilidad: ¿qué tan estable es nuestro plan?

En consecuencia, si el cumplimiento requiere entender qué tanto ha cambiado el plan original – o definido al inicio del periodo de tiempo, considerar una métrica que califiqué qué tanto ha variado el plan original puede ser muy útil y revelador para el equipo.

Calcular la variabilidad puede ser retador y requiere mucha disciplina. Lo que queremos evitar es trabajar en cosas que luego no aportan a nuestras métricas de ninguna manera. Por lo tanto, cada nueva actividad o tarea dentro de un periodo de tiempo debiera ser marcada o clasificada como parte o consecuencia del plan original, o nueva e inesperada.

Calidad: ¿qué tan bien hacemos el trabajo?

Bueno, no podíamos dejar por fuera la calidad. En este caso, me gusta considerar la calidad como una relación a la cantidad de trabajo entregado. Muchos equipos se limitan a «contar» los defectos o las incidencias. Esto, como ya debes saber, es un error. La medición no es métrica y, desde luego, mucho menos un indicador.

El diccionario define la calidad como:

Propiedad o conjunto de propiedades inherentes a algo, que permiten juzgar su valor.

Diccionario de la lengua española

Así es como una métrica de calidad que me gusta usar es lo que algunos autores denominan, defect-rate. ¿Qué porcentaje de la entrega está, en cierta forma, comprometida o afectada por problemas relacionados con la calidad?

Una métrica similar – y mi favorita – es la densidad de defectos. Esta métrica es una relación entre la cantidad de defectos y la entrega.

Métricas para proyectos ágiles

Desde luego, los proyectos pueden beneficiarse de las métricas de equipo. No obstante, a diferencia del equipo, estos avanzan hacia una terminación particular o cierre. De forma similar, las métricas de proyecto se pueden utilizar en el seguimiento a una liberación – release.

Progreso: ¿qué tanto hemos avanzado?

Al definir una meta a la cual llegar es posible establecer una métrica de progreso. Para lograrlo necesitamos una de las siguientes – aunque yo en lo personal intento establecer las dos:

1. Una fecha – milestone
2. Un objetivo específico – en función del producto o servicio en desarrollo

Con un límite o meta establecida podemos definir una métrica de progreso en función de la cantidad de trabajo completada y su impacto en el objetivo – algo que llaman muchas veces valor, en contraste con la capacidad total planificada para alcanzar el milestone.

¡Peligro! Progreso a terminación sobre un alcance variable

La mayor dificultad de medir el progreso en un «contexto» adaptativo es la constante búsqueda de cerrar el alcance. Es difícil, y para algunos incluso molesto, dar seguimiento al progreso sobre una meta que se mueve. Dentro del contexto ágil, se usa con frecuencia el concepto de objetivo o valor y se prefiere por encima de alcance. Así, el alcance puede variar en función del objetivo a lograr.

Ejemplo de objetivo fijo con alcance variable

Vamos con otro ejemplo, pero esta vez, dejemos tranquila a Joanna.

Es viernes a la noche y Pedro, un soltero próximo a cumplir 30 años, desea salir a divertirse. No obstante, no tiene mucho dinero y, mañana sábado tiene programado un almuerzo con sus padres al que desea asistir.

Entonces, Pedro ha definido:

1. Un objetivo claro
2. Un presupuesto estimado – un límite a los recursos
3. Un deadline – digamos que no quiere llegar con resaca al almuerzo con sus padres – o al menos tener la capacidad de disimular su resaca.

Sin embargo, Pedro no tiene un plan, y no tiene claro como ha de «divertirse». Así que veamos como el alcance es variable a la luz de objetivo.

Primer escenario

Pedro ha decidido llamar a sus amigos y reunirse con ellos en casa de uno de ellos. Si Pedro es como yo, seguramente beberán algunas cervezas, recordarán anécdotas de otro tiempo, tal vez algunos torneos en algún video juego y algo de pizza en algún momento de la noche. A eso de las 3am o 4am, Pedro estará en su casa, contento de reunirse con sus amigos y haber tenido una noche llena de «amistad».

Segundo escenario

Pedro ha decidido ir a su bar favorito. En el lugar se ha encontrado con a una persona que les gusta mucho y con la que existe una posibilidad clara de tener una gran noche. Es un momento de «flirteo», de romanticismo, es un momento de conquista. Pedro decide acercarse e intentarlo. Al otro día, sin muchos detalles, Pedro está feliz y siente que ha tenido una noche llena de «romance».

Tercer escenario

Pedro ha decidido ir a su bar favorito, pero no reconoce a nadie. Se siente algo solo, pero ve la oportunidad de conversar con nuevas personas. Entre algunos tragos y algo de buena música hace nuevos amigos. Al final del día está en su casa, conoce nuevas personas y siente que ha disfrutado de forma inesperada su bar favorito.

Cada uno de los escenarios plantea actividades y comportamientos diferentes dentro de un objetivo común y con unas restricciones iguales – conocidas en la jerga de proyectos como constraints. ¿Ahora si consideras posible variar el alcance en función del objetivo? No he dicho que sea simple, ni rápido, pero es posible en determinados contextos.

Endeudamiento: ¿qué tanto hemos agregado o negociado dentro o fuera del plan original?

Bueno, si tenemos una métrica de progreso, y sabemos que el alcance es variable, es una muy buena idea medir y darle seguimiento al nivel de endeudamiento del proyecto frente al plan. Es decir, qué porcentaje del trabajo originalmente planeado o proyectado ahora está fuera de las capacidades del equipo para la fecha y el objetivo establecido.

¿Qué pasa si Pedro está en una mesa de amigos nuevos y en ese momento aparece la persona que le gusta? Es inevitable, para la misma noche y con el mismo presupuesto, debe tomar decisiones. Cada decisión tendrá un costo y algunas actividades puntuales estarán fuera de su capacidad – para el periodo.

Ejemplos de métricas ágiles

Ahora te presento algunos ejemplos y los acompaño con algunas explicaciones que espero ayuden a cerrar los conceptos. Veamos.

Métricas ágiles de un equipo dedicado

Aunque el equipo nunca alcanza el 100% de cumplimiento del plan – cosa que en mi experiencia es el mejor escenario – si podemos determinar que tiene una velocidad real estable que ronda los 30_SP. Aunque podrías pensar que un equipo que planea debería cumplir el 100%, la verdad es que esta práctica compromete las estimaciones honestas y transparentes.

Nota que utilizo la palabra periodo y no Sprint, porque no es una obligación usar Scrum con estas métricas – aunque funciona bien.

Cumplir el 100% del plan de un Sprint o Periodo

Esta es una muy mala idea, y te voy a explicar por qué.

Imagina que haces parte de un equipo ágil y durante la planificación de la iteración han acordado completar requerimientos por un total de 100_SP. Durante la iteración, uno de sus compañeros se ha enfermado y no puede asistir, y algunos de los requerimientos se encuentran bloqueados por dependencias con un proveedor. ¿Qué significa esto?

1. Es claro que el equipo no va a lograr completar su meta de 100_SP.
2. Si no es culpa del equipo, no podríamos decir de inmediato que es una «mala planificación» – Este es un error común de quienes creen que las personas son máquinas y que los planes se deben cumplir al pie de la letra.
3. Lo más grave, de los 100_SP, el equipo ya no tiene elementos adicionales para tomar y reasignar trabajo y evitar una pérdida de tiempo.

¿Qué deberíamos hacer? ¿Deberíamos suspender la iteración? ¿Hacer una planificación de emergencia? ¿Qué sucede con el compromiso y las métricas ágiles?

El equipo no solo se encuentra bloqueado, no tiene otros elementos para tomar y «recomponer» su meta de 100_SP. Para los que disfrutan de las matemáticas, las estimaciones deben ser rangos y no puntos absolutos. Si la capacidad proyectada de un equipo es de 100_SP, el equipo debería planificar algo cercano a los 110_SP o 115_SP, entendiendo que puede tener días de alto desempeño. Así mismo, si algo con impacto negativo ocurre, el PO tiene «un plan B» para reorganizar al equipo entorno a aquello que si podemos trabajar.

Métricas ágiles «en problemas», ¿qué pasa?

A simple vista, algo ha ocurrido a partir del periodo 4. ¿Pero qué ha pasado? ¿Por qué está bajando la «velocidad real»?

La solución simple es, desde luego, aprovechar los espacios de reflexión con el equipo, identificar las causas y plantear soluciones. No obstante, a nivel directivo, expresar en datos lo que sucede puede ser útil. No siempre los directivos están en contacto constante con los equipos ágiles y se limitan a los reportes y las métricas. Así que, veamos un poco más de información sobre este caso.

Bueno, esta tabla extendida dice mucho. Por alguna razón, al equipo le han empezado a asignar trabajo no planificado dentro del mismo periodo – por ejemplo, ajustes a las funcionalidades existentes, cambios o mejoras. Nunca defectos.

¿Cuántos puntos debo asignar a los defectos?

Este es un punto de debate. ¿Debería o no cuantificar el esfuerzo de los defectos o incidentes que debemos corregir? Si y no. En mi experiencia, las métricas ágiles pueden manipularse si los incidentes o defectos tienen un peso en las métricas del equipo. Sin embargo:

1. Es bueno cuantificarlos para determinar el esfuerzo relativo.
2. Es malo cuantificarlos para determinar la velocidad del equipo.

En mi opinión, si un equipo debe invertir gran parte de su tiempo y capacidad en corregir errores – cosas que no funcionan como acordamos que deberían funcionar – el mejor reflejo en las métricas es una «pérdida de capacidad». De otra forma podrías tener equipos con puntajes relativos altos que no entregan nada más que defectos solucionados.

En conclusión, un equipo que invierte su tiempo en correcciones debería ver como su velocidad se reduce.

¿Existen métricas ágiles para la calidad del trabajo entregado?

Veamos un poco más de información de nuestro equipo ágil.

Contar los defectos de manera simple es una mala idea. Un defecto no es igual a otro. Algunos defectos requieren más trabajo que otros, así que es buena idea utilizar valores relativos para cuantificar los defectos – recuerdan que escribí «Es bueno cuantificarlos para determinar el esfuerzo relativo«.

Así que clasificarlos en tallas o usar algo similar a SP es buena idea.

No obstante, lo mejor es establecer una relación entre los SP entregados y los defectos inyectados en un periodo – es cierto, inyectar suena extraño.

En esta segunda oportunidad vemos como la densidad de defectos – cantidad de defectos inyectados por SP entregados aumenta. Es posible que, al introducir nuevos requerimientos al periodo, no esté estableciendo bien el plan o el impacto de dichos requerimientos. Esto, desde luego, afecta la capacidad de entregar – menor velocidad real – y la calidad de la entrega – mayor densidad de defectos.

Modelos a escala e Incrementos de Programa

Bueno, hasta ahora solo hemos discutido las métricas a nivel de equipo. Todas y cada una de las métricas presentadas se pueden usar en múltiples equipos – si usamos normalización – y para diferentes periodos, como las iteraciones, los meses y los incrementos de programa (PI).

Si aún te ofende la «variabilidad» piensa en lo siguiente:

1. Es posible que decidas no aceptar nada dentro de una misma iteración.
2. Aquello adicional o nuevo entrará en la siguiente iteración – variabilidad 0% de la iteración
3. No obstante, esa iteración hace parte de un PI, y por lo tanto, es prudente medir la variabilidad de la iteración para mejorar las mediciones y proyecciones durante el siguiente PI Planning.

Consideraciones

Como ves, las métricas ágiles aplican para proyectos ágiles, equipos ágiles y temas a gran escala. Si solo mantienes las métricas para el equipo, pierdes la oportunidad de escalar. En organizaciones grandes, con cientos o miles de empleados, no es posible realizar retrospectivas y comunicar fácilmente las razones y las acciones. Por eso, establecer métricas y apoyar la buena lectura y comprensión de estas, te puede ayudar a ganar el apoyo organizacional que necesitas. Todos necesitamos del apoyo «político» en una gran organización es clave, y dar visibilidad de lo que ocurre es el primer paso para obtenerlo.

¡Comparte!