En la primera publicación establecimos qué son las métricas en Scrum y los beneficios de basar las decisiones del equipo en datos objetivos. En esta segunda publicación, vamos a ver cuáles son las métricas más utilizadas y su clasificación en 5 grandes grupos en función de lo que pretende medir cada métrica. Estos cinco grupos son:
1. Métricas de Productividad y Capacidad.
2. Métricas de Flujo.
3. Métricas de Eficacia y Valor.
4. Métricas de Calidad del Producto.
5. Métricas de Salud del Equipo.
MÉTRICAS DE PRODUCTIVIDAD Y CAPACIDAD
Estas métricas cuantifican cuánto trabajo puede realizar el equipo y ayudan a estabilizar las planificaciones futuras; el Sprint Planning.
- Velocidad (Velocity): Es el promedio de Puntos de Historia (PH) completados y aceptados en los últimos Sprints, se suele tomar como referencia los últimos 3 o 4 sprints.
Ejemplo: Un equipo completa 30 PH en el Sprint 1, 35 PH en el Sprint 2 y 31 PH en el Sprint 3. Su velocidad actual es de 32 PH. Esta es la cifra que usarán como límite de capacidad teórica para el Sprint 4.
- Capacidad Real (Capacity): Mide las horas efectivas de las que dispone el equipo en un Sprint determinado, restando días festivos, vacaciones y el porcentaje de tiempo destinado a reuniones, más conocido como “overhead.”
Ejemplo: Un equipo de 5 personas en un Sprint de 10 días tiene 400 horas teóricas. Si restamos un 20% de ceremonias Scrum y 1 día de vacaciones de un miembro, la Capacidad Real es de 312 horas.
- Ratio de Compromiso (Say/Do Ratio): Calcula el porcentaje de Puntos de Historia entregados frente a los Puntos de Historia comprometidos al inicio del Sprint.
Ejemplo: El equipo se comprometió a entregar 40 PH, pero el Product Owner sólo aceptó 34 PH. El ratio de compromiso es del 85%. Un ratio consistentemente por debajo del 80% indica problemas en el proceso de estimación o dependencias externas no resueltas.
MÉTRICAS DE FLUJO
Miden la eficiencia del proceso desde que se solicita un trabajo hasta que se finaliza. Son esenciales para identificar cuellos de botella.
- Tiempo de Ciclo (Cycle Time): El tiempo exacto que transcurre desde que un desarrollador mueve una tarea a "In Progress" hasta que pasa a "Done".
Ejemplo: Un desarrollador empieza una Historia de Usuario el martes a las 10:00 y la termina el jueves a las 10:00. El Cycle Time es de 2 días.
- Tiempo de Entrega (Lead Time): El tiempo que transcurre desde que una necesidad se crea y entra en el Product Backlog hasta que está completamente finalizada y entregada al cliente.
Ejemplo: Un cliente solicita una funcionalidad el 1 de marzo. Pasa al Backlog, se planifica en un Sprint posterior y se despliega el 20 de marzo. El Lead Time es de 20 días.
- Trabajo en Curso (WIP - Work In Progress): El número de elementos en los que el equipo está trabajando simultáneamente en un momento dado.
Ejemplo: Un equipo de 4 personas tiene 12 historias en la columna "In Progress". Un WIP tan alto (3 tareas por persona) indica falta de foco y provocará un aumento directo en el Cycle Time.
MÉTRICAS DE EFICACIA Y VALOR
Evalúan si el equipo está construyendo el producto correcto y cumpliendo las expectativas de negocio, más allá de la simple entrega de código.
- Cumplimiento del Objetivo del Sprint (Sprint Goal Success): Métrica binaria o porcentual que determina si se alcanzó la meta de negocio definida en el Sprint Planning, independientemente de si quedaron tareas menores sin terminar.
Ejemplo: El equipo no terminó 2 tareas de baja prioridad, pero el sistema de pagos (el Sprint Goal) fue desplegado y funciona. El cumplimiento es del 100%.
- Retorno de Inversión (ROI) por Funcionalidad: Compara el coste de desarrollo de una Historia de Usuario frente al beneficio económico o de uso generado.
Ejemplo: Desarrollar una pasarela de pago costó el equivalente a 3.000€ en horas de equipo, pero aumentó las conversiones generando 15.000€ el primer mes.
MÉTRICAS DE CALIDAD DEL PRODUCTO
Miden la excelencia técnica del entregable. Aseguran que la velocidad del equipo no genere deuda técnica o software inestable.
- Densidad de Defectos: El número de bugs o errores detectados en relación con el tamaño del software entregado, medido en Puntos de Historia o líneas de código.
Ejemplo: Tras entregar una funcionalidad de 50 Puntos de Historia, el equipo de QA detecta 5 errores. La densidad es de 0.1 defectos por PH.
- Defectos Escapados (Escaped Defects): Los errores críticos que no fueron detectados durante el Sprint y son reportados por los usuarios finales en producción.
Ejemplo: En el último mes, los usuarios reportaron 4 bugs en la aplicación en vivo. Esta métrica debe tender a cero; de lo contrario, la Definition of Done (DoD) requiere revisión urgente.
- Cobertura de Código (Code Coverage): Porcentaje del código fuente que es ejecutado y validado por los test unitarios.
Ejemplo: El 85% de las funciones clave del software están cubiertas por tests automáticos, reduciendo el riesgo de rotura en futuros Sprints.
MÉTRICAS DE SALUD DEL EQUIPO
Scrum requiere equipos sostenibles y motivados. Estas métricas anticipan problemas de rendimiento causados por fatiga o desmotivación.
- Índice de Felicidad (Team Morale / Happiness Metric): Encuesta cuantitativa realizada habitualmente durante la Retrospectiva del Sprint.
Ejemplo: Cada miembro puntúa del 1 al 5 su nivel de satisfacción con el último Sprint. Una media que cae de 4.5 a 3.0 en dos Sprints consecutivos alerta al Scrum Master de un posible burnout (agotamiento) o conflictos internos.
- Rotación del Equipo (Team Turnover): Frecuencia con la que los miembros abandonan el equipo Scrum.
Ejemplo: Un equipo ha cambiado a 3 de sus 5 miembros en seis meses. Una rotación alta destruye la Velocidad del equipo, ya que requiere tiempo constante de integración y curva de aprendizaje.
Add new comment