Métricas Scrum: Velocity, Burndown Chart y Burnup Chart

Scrum es empírico: se basa en la observación y la adaptación. Las métricas en Scrum no son para controlar personas, sino para:

• Entender la capacidad real del equipo
• Hacer predicciones más confiables sobre fechas de entrega
• Identificar obstáculos sistémicos
• Tomar decisiones basadas en evidencia

La Velocity es la cantidad de Story Points que un equipo Scrum completa en promedio por Sprint.

Cálculo: Story Points completados en el Sprint (solo los que cumplen la Definición de Done)

Ejemplo:

• Sprint 1: 23 puntos
• Sprint 2: 27 puntos
• Sprint 3: 25 puntos
• Sprint 4: 29 puntos
• Sprint 5: 26 puntos
• Velocity promedio = 26 puntos por Sprint

Para qué sirve la Velocity:

Planificación de releases: Si el backlog tiene 150 puntos y la velocity es 26 puntos/Sprint, el equipo necesita aproximadamente 6 Sprints.

Sprint Planning: El equipo no debería comprometerse a más puntos de los que su velocity indica.

Identificación de problemas: Una caída significativa puede indicar: incorporación de nuevos miembros, deuda técnica acumulada, impedimentos no resueltos.

Lo que la Velocity NO es:

• No es una métrica de productividad individual
• No es comparable entre equipos
• No debe usarse para presionar al equipo

Velocity estable vs. errática:

• Estable (saludable): 23, 26, 25, 28, 26, 27
• Errática (problema): 35, 10, 42, 8, 38, 12

El Burndown Chart muestra el trabajo restante (en puntos) a lo largo del tiempo. Visualmente indica si el equipo va completando el trabajo al ritmo necesario.

Cómo leerlo:

• Eje X: Días del Sprint
• Eje Y: Puntos restantes
• Línea ideal: Diagonal desde el total de puntos hasta cero en el último día
• Línea real: El progreso efectivo del equipo

Patrones del Burndown:

Patrón 1 - Burndown ideal: La línea real sigue la ideal. El equipo trabaja a ritmo constante.

Patrón 2 - Plano al inicio, baja rápido al final: Dificultades al inicio, aceleración al final. Riesgo de calidad.

Patrón 3 - No llega a cero: El equipo sobre-comprometió en el Sprint Planning.

Patrón 4 - Sube en algún punto: Se añadió trabajo al Sprint. Scope creep.

Patrón 5 - Llega a cero antes de tiempo: El equipo terminó antes. Pueden tomar historias adicionales.

Sprint Burndown vs. Release Burndown:

• Sprint Burndown: Progreso dentro de un Sprint (días en el eje X)
• Release Burndown: Progreso hacia una versión completa (Sprints en el eje X)

El Burnup Chart muestra el trabajo completado (sube) en lugar del trabajo restante (que baja).

Dos líneas:

1. Línea de trabajo completado: Sube con cada Sprint.
2. Línea de scope total: El total del backlog (puede cambiar si se añaden o eliminan ítems).

Ventajas del Burnup sobre el Burndown:

Visibilidad del scope creep: Si el scope total crece, la línea superior sube y es inmediatamente visible.

Más motivador: Ver el trabajo completado crecer es psicológicamente más positivo.

Mejor para stakeholders: Los ejecutivos encuentran más intuitivo ver cuánto se hizo vs. cuánto queda.

Sprint Goal Achievement Rate: Porcentaje de Sprints donde se alcanzó el Sprint Goal. Si es menor al 80%, hay problemas de planificación.

Team Happiness: Métrica cualitativa de satisfacción del equipo. Indicador temprano de burnout.

Bug Rate: Número de bugs por sprint. Una tasa alta y creciente indica deterioro en la calidad.

1. Comparar Velocity entre equipos: Los story points son relativos a cada equipo.

2. Presionar para aumentar la Velocity: Resulta en estimaciones infladas y deuda técnica.

3. Ignorar las métricas: Sin datos, las decisiones se basan en intuición y política.

4. No actualizar el Burndown diariamente: Un Burndown actualizado cada 3 días no sirve.

5. Contar puntos de historias no completadas: Solo cuentan historias que cumplen 100% la Definición de Done.

Resumen de la Lección

• La Velocity es el promedio de story points completados por Sprint. Para planificación, no para presionar al equipo.
• El Burndown Chart muestra el trabajo restante vs. el tiempo.
• El Burnup Chart muestra el trabajo completado y el scope total. Mejor para comunicar con stakeholders.
• Las métricas deben usarse para mejorar el sistema, no para evaluar individuos.

Felicitaciones por completar el Módulo 2. En el próximo módulo, exploraremos Kanban.