Mide éxito con métricas ágiles como velocity y burn-down

Concepto clave

En el mundo del Product Management con metodologías ágiles, medir el éxito no se trata solo de lanzar un producto, sino de entender cómo evoluciona el trabajo del equipo y el valor entregado. Dos métricas fundamentales son el velocity y el burn-down chart. Piensa en ellas como el "velocímetro" y el "mapa de combustible" de tu proyecto ágil.

El velocity mide la cantidad de trabajo que un equipo Scrum completa en un sprint, expresado en puntos de historia. No es una meta, sino una herramienta de pronóstico: ayuda a predecir cuánto trabajo puede hacerse en sprints futuros, basándose en el rendimiento pasado. Imagina que eres un corredor entrenando para una maratón: tu velocidad en carreras cortas te da una idea de cuánto podrías correr en la competencia principal, pero no debes forzarte a ir más rápido de lo sostenible.

El burn-down chart es un gráfico que muestra el trabajo restante en un sprint o proyecto a lo largo del tiempo. Visualmente, traza una línea que idealmente "quema" hacia cero a medida que el equipo completa tareas. Es como ver el nivel de gasolina en tu auto durante un viaje: si la línea desciende de manera constante, vas bien; si se aplana, podrías quedarte sin combustible antes de llegar.

"Lo que no se mide no se puede mejorar." - Esta idea aplica directamente: sin métricas como velocity y burn-down, es difícil optimizar procesos en Agile.

Cómo funciona en la práctica

Veamos un ejemplo paso a paso para un equipo de Product Management trabajando en una nueva funcionalidad de una app móvil, usando un sprint de 2 semanas (10 días hábiles).

1. Planificación del sprint: El equipo estima 40 puntos de historia para el backlog del sprint, basándose en historias de usuario como "Como usuario, quiero iniciar sesión con redes sociales".
2. Seguimiento diario: Cada día, en la daily stand-up, actualizan el trabajo completado. Por ejemplo, al final del día 3, han terminado 15 puntos.
3. Cálculo del velocity: Al final del sprint, suman los puntos completados: digamos 38 puntos. Este es el velocity del sprint. Si en sprints anteriores tuvieron 35 y 40 puntos, pueden pronosticar un rango de 35-40 para el próximo sprint.
4. Creación del burn-down chart: Usan una tabla para rastrear:

   Día	Trabajo restante (puntos)
   1	40
   2	38
   3	35
   4	32
   5	30
   6	25
   7	20
   8	15
   9	10
   10	2

   La línea ideal iría de 40 a 0 en una pendiente constante, pero en la realidad, fluctuaciones como esta son normales y revelan bloqueos.

Caso de estudio

Un equipo de Product Management en una startup tech estaba desarrollando una plataforma de e-learning. En su tercer sprint, planificaron 50 puntos de historia para agregar un sistema de quizzes. Usaron velocity y burn-down para medir el éxito:

• Velocity histórico: En sprints 1 y 2, completaron 45 y 48 puntos, respectivamente, dando un promedio de 46.5.
• Burn-down en acción: Al día 5, el burn-down chart mostraba solo 10 puntos completados, con 40 restantes, indicando un retraso. El Product Manager identificó que una dependencia técnica no estaba resuelta.
• Acción tomada: Revisaron el backlog, removieron 10 puntos de baja prioridad, ajustando la meta a 40 puntos. Al final, completaron 42 puntos, con un velocity de 42 para ese sprint, y aprendieron a validar dependencias antes de planificar.
• Resultado: Lanzaron los quizzes a tiempo, y el velocity se estabilizó en 45-50 en sprints posteriores, mejorando la predictibilidad.

Errores comunes

• Usar velocity como meta: Algunos equipos presionan para aumentar el velocity cada sprint, lo que lleva a estimaciones infladas o burnout. En su lugar, úsalo como indicador de capacidad, no de desempeño.
• Ignorar el contexto del burn-down: Si el chart muestra una línea plana, no solo digas "vamos mal". Investiga causas como bloqueos técnicos o scope creep, y ajusta en retrospectivas.
• No actualizar métricas diariamente: Sin datos frescos, el burn-down pierde utilidad. Establece un hábito en las dailies para mantenerlo relevante.
• Comparar velocities entre equipos: Cada equipo tiene su propia velocidad basada en factores únicos. Comparar puede crear competencia insana; enfócate en tendencias internas.
• Olvidar el valor del producto: Velocity mide cantidad de trabajo, no calidad o impacto. Complementa con métricas de negocio como tasa de adopción o satisfacción del usuario.

Checklist de dominio

• Puedo explicar la diferencia entre velocity y burn-down en una oración clara.
• He calculado el velocity de al menos un sprint hipotético usando puntos de historia.
• Puedo dibujar un burn-down chart básico con datos de un sprint simulado.
• Identifico al menos un error común al usar estas métricas y sé cómo evitarlo.
• Uso velocity para pronosticar la capacidad del equipo en la planificación de sprints.
• Integro insights del burn-down en retrospectivas para mejorar procesos.
• Comunico métricas ágiles a stakeholders no técnicos de manera comprensible.

Simula el seguimiento de un sprint con velocity y burn-down

En este ejercicio, actuarás como Product Manager de un equipo que desarrolla una app de fitness. Sigue estos pasos para aplicar métricas ágiles:

1. Define el sprint: Asume un sprint de 2 semanas (10 días) con un backlog de 60 puntos de historia, distribuidos en tareas como "agregar seguimiento de pasos" (15 puntos), "implementar recordatorios" (20 puntos) y "optimizar interfaz" (25 puntos).
2. Registra el progreso diario: Simula el trabajo completado cada día:
   • Día 1: 5 puntos
   • Día 2: 10 puntos
   • Día 3: 8 puntos
   • Día 4: 12 puntos
   • Día 5: 7 puntos
   • Día 6: 10 puntos
   • Día 7: 6 puntos
   • Día 8: 10 puntos
   • Día 9: 8 puntos
   • Día 10: 4 puntos
3. Calcula el velocity: Suma los puntos completados al final del sprint. ¿Cuál es el velocity? Usa esto para pronosticar: si el próximo sprint tiene 70 puntos estimados, ¿es realista basado en este velocity?
4. Crea un burn-down chart: Usa una tabla HTML o dibújalo en papel. Traza los días en el eje X y el trabajo restante en el eje Y, empezando en 60. Actualiza después de cada día basado en el progreso simulado. Analiza: ¿la línea se acerca a cero? ¿Hay días con poco progreso que indiquen problemas?
5. Reflexiona y actúa: Escribe un breve informe (2-3 párrafos) explicando qué aprendiste del velocity y burn-down, y sugiere una mejora para el próximo sprint basada en los datos.

• Recuerda que el velocity es la suma total de puntos completados, no un promedio diario.
• Para el burn-down, resta el progreso diario del trabajo restante acumulado.
• Si el velocity es bajo comparado con la estimación, considera ajustar el scope o investigar bloqueos en la retrospectiva.

Evalua tu comprension

Completa el quiz interactivo de arriba para ganar XP.