El progreso de un proyecto con Scrum se mide principalmente con dos herramientas: el burndown chart y la velocidad del equipo.
El día que el gerente no supo qué contestar
Era un martes por la tarde en las oficinas de Liverpool en Polanco. El gerente de proyectos digitales estaba en una videollamada con su director. La pregunta fue directa: "¿Cómo vamos con el nuevo módulo de pagos?"
El gerente tardó casi un minuto en responder. Abrió tres archivos de Excel, revisó correos y al final dijo algo vago: "Creo que vamos bien, más o menos a la mitad."
Ese "más o menos" le costó caro. El proyecto llegó tarde, y nadie lo vio venir. Lo curioso es que el equipo sí tenía toda la información necesaria para saber que iban mal. Solo no sabían cómo leerla.
Por qué el avance no se mide en porcentajes
Cuando alguien dice que un proyecto va "60% avanzado", esa cifra no significa casi nada. ¿El 60% de qué? ¿De tareas? ¿De horas? ¿De funciones entregadas?
Scrum resuelve este problema con una filosofía simple: mide el trabajo que ya está terminado, no el que está en proceso. Un equipo que lleva tres Sprints y ha entregado funcionalidades reales sabe exactamente dónde está. Un equipo que lleva tres Sprints con "cosas casi listas" no sabe nada.
Esta distinción parece pequeña, pero cambia todo. Según datos de organizaciones que adoptan marcos ágiles, los proyectos que miden solo el avance terminado tienen un 34% más de probabilidad de entregar a tiempo que los que miden el avance estimado. La diferencia está en lo que cuentas.
El burndown chart: ver el futuro en una gráfica
El burndown chart es una gráfica de dos ejes. En el eje horizontal están los días del Sprint. En el eje vertical están los Story Points que quedan por completar.
Al inicio del Sprint, la barra está arriba. Cada día que el equipo termina trabajo, la línea baja. Al final del Sprint, la línea debería llegar a cero.
Hay dos líneas en la gráfica. La primera es la línea ideal: una diagonal perfecta que baja a ritmo constante. La segunda es la línea real: la que dibuja el equipo con su trabajo diario.
Cómo leer la gráfica sin ser experto
Imagina que el equipo de FEMSA tiene un Sprint de 10 días con 50 Story Points comprometidos. La línea ideal baja 5 puntos por día. Si el día 4 la línea real está en 38 puntos en lugar de 30, hay un retraso. El equipo necesita acelerar o renegociar el alcance.
Si la línea real está por debajo de la ideal, el equipo va adelantado. Eso puede significar que estimaron con demasiado margen, o que están trabajando especialmente bien ese Sprint.
Lo fascinante del burndown chart es que te dice la verdad sin opiniones. No importa lo que diga el gerente en la reunión. La gráfica muestra lo que está pasando.
El error más común con el burndown chart
Muchos equipos actualizan el burndown chart solo una vez por semana, o peor, solo al final del Sprint. Eso lo convierte en un espejo retrovisor, no en un volante.
El burndown chart funciona cuando se actualiza cada día, durante o justo después del Daily Scrum. Así el equipo puede reaccionar a tiempo, no cuando ya es demasiado tarde.
La velocidad del equipo: el dato que lo cambia todo
La velocidad es el número de Story Points que un equipo termina en un Sprint. Es una métrica histórica. No predice el futuro con certeza, pero sí te da la mejor estimación posible.
Supón que el equipo de desarrollo de Bimbo Digital completa estos Story Points en cuatro Sprints consecutivos: 32, 28, 35 y 31. La velocidad promedio es 31.5 puntos por Sprint.
Con esa cifra, el Product Owner puede calcular algo muy valioso: si el Product Backlog tiene 120 Story Points pendientes, el equipo necesitará aproximadamente 4 Sprints más para terminarlo. Eso es información concreta para planear lanzamientos, avisar a usuarios o ajustar presupuestos.
Por qué la velocidad no se usa para presionar
Aquí viene un error que destruye equipos. Algunos gerentes ven la velocidad y piensan: "Si el equipo hizo 32 puntos este Sprint, deberían poder hacer 40 el siguiente."
Eso no funciona así. La velocidad es una herramienta de predicción, no de presión. Cuando los equipos se sienten forzados a inflar su velocidad, empiezan a dividir tareas grandes en subtareas más pequeñas solo para sumar puntos, o bajan la calidad del trabajo para terminar más rápido. Ambas cosas dañan el proyecto.
La velocidad es útil solo cuando refleja el ritmo natural y sostenible del equipo.
Herramientas visuales para el tablero del equipo
Además del burndown chart y la velocidad, los equipos ágiles usan tableros visuales para ver el estado del trabajo en tiempo real. Ya vimos el tablero Kanban en lecciones anteriores: columnas de "Por hacer", "En progreso" y "Terminado".
Dentro de Scrum, este tablero se llama Sprint Board o tablero del Sprint. Cada tarjeta representa una historia de usuario o tarea. El equipo mueve las tarjetas durante el Sprint hasta que todo llega a la columna de terminado.
Herramientas como Jira, Trello o Azure DevOps generan el burndown chart automáticamente cuando el equipo actualiza el tablero. Eso elimina el trabajo manual y reduce los errores.
Lo que le pasó al equipo de Liverpool
Volvamos a Polanco. Después del proyecto fallido, el equipo adoptó Scrum con tablero digital y burndown chart diario.
En el primer Sprint del nuevo módulo de notificaciones, el día 6 de 10 la línea real estaba por encima de la ideal: les quedaban 22 puntos y solo tenían 4 días. En el Daily Scrum de ese día, el equipo identificó que dos historias estaban bloqueadas porque el área de seguridad no había aprobado los permisos de API.
El Scrum Master escaló el bloqueo ese mismo día. Los permisos llegaron al día siguiente. El equipo ajustó prioridades y terminó el Sprint con 42 de 50 puntos. No fue perfecto, pero tomaron la decisión correcta con información real, no con suposiciones.
El gerente, en la siguiente videollamada con su director, abrió el burndown chart en pantalla y explicó exactamente qué había pasado y cómo lo resolvieron. Tardó menos de dos minutos.
Errores comunes al medir el progreso
El primer error es confundir actividad con avance. Un equipo muy ocupado que no termina historias completas no avanza. Solo se cansa.
El segundo error es no actualizar las métricas con frecuencia. Un burndown chart que se actualiza cada semana no sirve para tomar decisiones durante el Sprint.
El tercer error es comparar velocidades entre equipos diferentes. Si el equipo de Mercado Libre hace 60 puntos por Sprint y el tuyo hace 25, no significa que tu equipo sea peor. Los Story Points son relativos a cada equipo y su propia escala. Comparar velocidades entre equipos es como comparar temperaturas en Celsius y Fahrenheit sin convertir: los números no significan lo mismo.
Lo que cambia cuando mides bien
Cuando un equipo aprende a leer su burndown chart y conoce su velocidad, algo cambia en las conversaciones. Dejan de hablar de "creemos" y "esperamos". Empiezan a hablar de datos.
"Nuestra velocidad promedio es 30 puntos. El backlog tiene 90 puntos. Podemos entregar todo en 3 Sprints, es decir, en 6 semanas."
Esa frase vale más que cualquier presentación con diapositivas. Y la puedes construir tú, con la información que Scrum pone en tus manos desde el primer Sprint.