El otro día un colega me enseñó su dashboard de Jira. Todo verde, burndown perfecto, velocity estable. Le dije "tío, enhorabuena". Me miró raro. "Si llevamos tres sprints sin subir nada a producción". Pues eso. Los dashboards mienten. Bueno, no mienten exactamente — miden lo que es fácil de medir, que no es lo mismo que lo que necesitas saber.
Y mira, no es culpa de Jira. Ni de Azure DevOps. Ni de Linear. Estas herramientas hacen lo que hacen y lo hacen bien. El problema es que hay un montón de métricas que importan muchísimo y que ninguna de ellas te da. ¿Cuánto tiempo lleva ese ticket "en progreso" que nadie toca desde hace dos semanas? ¿Qué pasa si tu tech lead se pone enfermo mañana y resulta que es el único que sabe configurar los pipelines? ¿A qué ritmo entra trabajo nuevo en el backlog comparado con lo que sacáis?
Esas preguntas me llevaban rondando meses. Así que hice lo que cualquier ingeniero haría: me puse a construir herramientas para responderlas yo mismo. Son 6. Todas corren en el navegador. Sin login, sin servidores, sin mandar datos a ningún sitio. Si te sirven, genial. Si no, pues al menos he aprendido un montón haciéndolas.
Tu WIP te está mintiendo en la cara
La primera cosa que construí fue el Gráfico de Antigüedad WIP. La mayoría de equipos saben cuántos tickets tienen "en progreso" — eso es fácil, lo ves en cualquier tablero. Pero cuánto TIEMPO llevan ahí... eso ya es otra historia.
A ver, piénsalo un segundo. Si tienes 8 tickets en progreso y todos se abrieron ayer, vas fenomenal. Si tienes 8 tickets y tres de ellos llevan 20 días, tienes un problema gordo que la cifra "8 WIP" no te va a contar. Daniel Vacanti lleva años insistiendo en que la edad del WIP es probablemente la métrica más infravalorada del mundo agile. Y después de usar esta herramienta unas semanas con mi equipo, estoy bastante convencido de que tiene razón.
La gracia es que funciona como indicador adelantado. El cycle time te dice lo que ya pasó. La edad del WIP te dice lo que está a punto de salir mal. Que es mucho más útil, la verdad.
Seis dimensiones porque "¿cómo va el equipo?" no tiene respuesta corta
Segundo invento: el Radar de Seis Dimensiones. ¿Tu equipo va bien? Depende. ¿En qué? Porque conozco equipos que entregan rapidísimo pero con una calidad que da vergüenza ajena. Y equipos con un código impecable que tardan tres sprints en sacar cualquier cosa.
El radar te obliga a evaluar seis cosas diferentes: Calidad, Velocidad de Respuesta, Previsibilidad, Productividad, Flujo y Valor. Produces un diagrama de araña y ves dónde estás fuerte y dónde flojeas. No es ciencia exacta — es una herramienta para tener la conversación, no para sustituirla.
Lo que me mola es guardar snapshots de diferentes momentos y compararlos. Tipo "así estábamos en enero, así estamos ahora, mira cómo ha mejorado la previsibilidad pero la calidad ha bajado dos puntos". Eso en una retro vale oro.
La hoja de cálculo del bus factor que nadie mantiene
Tercer bicho: el Analizador de Brechas de Capacidad. Casi todos los equipos en los que he estado tienen una de estas hojas — la típica matriz de skills con nombres en las filas y tecnologías en las columnas. Y casi todos la tienen desactualizada desde hace seis meses.
El tema del bus factor es que todo el mundo sabe que es un riesgo y nadie hace nada al respecto hasta que pasa. Alguien se va de vacaciones, o se cambia de empresa, o simplemente se pone malo — y de repente descubres que era la única persona que sabía manejar el sistema de pagos. He visto esto pasar cuatro veces en dos años. CUATRO. Y cada vez es el mismo "bueno, es que no habíamos mapeado bien las capacidades". Ya, claro.
La herramienta te deja mapear habilidades contra personas, marcar lo que es crítico para el futuro, y te pinta en rojo todo lo que tiene cobertura de una sola persona. Que luego hagas algo con esa información ya es cosa tuya, pero al menos la tienes.
Formar equipos debería ser un problema de diseño, no de suerte
El Optimizador de Formación de Equipos nació de una frustración muy concreta. Vi cómo una empresa reorganizaba sus equipos y básicamente lo hicieron por disponibilidad en el calendario. "Tú estás libre, tú estás libre, venga, sois equipo". El resultado fue un equipo con cuatro desarrolladores backend y cero frontend, y otro al revés.
Conway nos avisó de que la estructura del equipo acaba reflejándose en la arquitectura. Team Topologies lo formalizó de manera brillante. Y aun así seguimos formando equipos como si fuera algo que se puede improvisar un viernes por la tarde.
La herramienta no sustituye el criterio humano — las dinámicas personales y la química importan, y eso no lo captura ningún algoritmo. Pero te da un punto de partida basado en cobertura de habilidades en vez de en quién estaba disponible cuando tocó reorganizar.
"¿Cuánto trabajo va a entrar?" es un problema de forecasting
Quinto chisme: el Pronóstico de Tasa de Llegada al Backlog. Esto es algo que casi nadie mide y que cambia completamente cómo planificas.
Tu equipo completa 12 items por sprint. Bien. Pero si entran 15 nuevos cada sprint, tu backlog crece. En 10 sprints tienes 30 items más que al principio. Ningún burndown te cuenta esto. Ningún velocity chart te avisa. Y un día miras el backlog y tiene 200 tickets y no entiendes cómo ha pasado.
La herramienta usa descomposición estacional — básicamente identifica si hay patrones en cómo llega el trabajo. ¿Hay picos después de las demos? ¿Se calma en agosto? ¿La tendencia va a más o a menos? Lo de Hyndman y Athanasopoulos sobre forecasting es muy completo si te quieres meter a fondo, pero la herramienta te da los resultados sin necesidad de estudiar estadística.
Planificar capacidad contando con que la realidad existe
Y por último, el Planificador de Capacidad Estacional. Este es el más pragmático de los seis y probablemente el que más uso yo en mi día a día.
Todos sabemos que en agosto y en Navidades la capacidad baja. Todos sabemos que después de una ronda de contratación hay unas semanas de onboarding donde la productividad cae. Y sin embargo hay gente que planifica sprints como si tuviera al equipo al 100% todo el año. Luego vienen las sorpresas, los "es que no llegamos", los compromisos incumplidos.
Esta herramienta te deja poner factores estacionales (agosto al 60%, diciembre al 70%, whatever) y cruzarlos con la demanda prevista. Así cuando alguien te pida comprometerte a entregar algo en agosto, le puedes enseñar los números en vez de intentar explicar con palabras que "es que en agosto la gente se va de vacaciones". Esto conecta con la Teoría de Restricciones — la capacidad del sistema la marca el cuello de botella, no el recurso más disponible.
Todo esto corre en tu navegador
Ninguna de estas herramientas necesita backend. No hay login. No hay base de datos. Tus datos se guardan en localStorage y puedes exportar e importar JSON cuando quieras. Los parámetros de configuración van en la URL, así que puedes compartir una configuración específica simplemente copiando el enlace.
¿Por qué lo hice así? Porque los datos de tu equipo — quién sabe qué, cuánto tarda cada cosa, cuánta capacidad tenéis — son sensibles. No deberían estar en el servidor de una startup de San Francisco que puede pivotar mañana. Deberían estar en tu máquina.
Pruébalas. Si te resultan útiles, guay. Si les ves mejoras, dímelo. Y si crees que falta alguna métrica que nadie mide, probablemente tengas razón y probablemente acabe construyéndola.