Hackeá tu Sprint #
De rellenar horas a predecir el futuro** #
Viernes a la tarde, cuando ya cerrabas la semana, caíste en la cuenta: no cargaste las horas en Azure DevOps (o en Jira). Entraste en ese pánico leve, tratando de recordar a medias qué habías hecho el martes… y al final, terminaste inventando números hasta que el contador marcó 40 horas limpias.
Si te pasa esto, tu herramienta de gestión no sirve para trabajar, es solo un trámite burocrático.
El problema está en que, cuando el equipo siente que lo miden por “ocupación” (contar horas) y no por resultados, la información pierde valor. Aquí van algunas ideas para darle vuelta a esto, tanto en equipo como a nivel personal.
Primera parte: Cambio de mentalidad en el equipo #
(Dejar el “control” por la guía) #
Para que herramientas como Azure DevOps funcionen, hay que usarlas no como un reloj para fichar, sino como un GPS.
1. Enfocate en el “Remaining Work”, no en el “Completed Work” #
Lo más valioso no es lo que ya hiciste (eso ya pasó), sino lo que falta terminar.
Cambio: dejá de pedir que el tiempo completado cierre perfectamente. Enfocate en que cada día se actualice el trabajo restante.
Beneficio: eso alimenta el Burndown Chart. Si el equipo actualiza cuánto falta, el martes ya sabés si no vas a llegar el viernes.
2. La regla de las 8 horas #
Las tareas gigantes son agujeros negros donde se esconden los retrasos.
- Táctica: no dejes que una tarea supere las 8 horas estimadas.
- Por qué sirve: si una tarea es de 40 horas, el avance es invisible. Si son cinco de 8 horas, ves el movimiento en el tablero cada día.
3. Automatizá lo burocrático #
Si registrar información duele, nadie lo va a hacer.
Segunda parte: Tu mejora individual #
(Cómo estimar como alguien que sabe) #
No hace falta ser Scrum Master para mejorar. Podés aplicar ingeniería a tu propia gestión del tiempo y dejar de sufrir con fechas imposibles.
1. Microgranularidad defensiva #
Nuestro cerebro es malo para estimar en días, pero bueno para estimar en horas.
Técnica: si tenés una tarea de 8 horas, dividila (solo para vos) en subtareas de 1 a 4 horas. Por ejemplo: “Diseñar JSON”, “Mockear servicio”, “Hacer test unitario”.
Resultado: la complejidad oculta sale a la luz antes de comprometer una fecha.
2. Calculá tu “factor de fricción” #
Estimamos pensando en un mundo ideal, pero en la realidad hay reuniones, mensajes y consultas.
- Probá esto: durante una semana, anotá cuántas horas reales de código puro lográs por día. Lo más probable es que sean 5, no 8.
- Fórmula: si una tarea creés que te va a tomar 4 horas, reservá 6 en tu calendario. Ese multiplicador (1,5x) es tu seguro de vida.
3. Usá la técnica de los 3 puntos (PERT simple) #
Cuando te pregunten “¿cuánto tardás?”, nunca des un solo número. Tu instinto tiende al optimismo. Pensá en tres escenarios: - Optimista (O): todo sale bien. - Pesimista (P): todo se rompe. - Probable (M): lo normal.
Fórmula:
(Optimista + 4 × Probable + Pesimista) ÷ 6
Este promedio pesado te da una estimación más honesta y profesional que la intuición sola.
Para cerrar #
Mejorar la calidad de la información no es ser más estricto con la carga de horas, es cambiar el incentivo.
- Al equipo: “No me importa que completes 40 horas, me importa saber si llegamos al release”.
- A vos mismo: “No estimo para impresionar, estimo para cumplir”.
Podés empezar de a poco: en la próxima daily, mirá el tablero y preguntá por el trabajo restante, no por lo que ya pasó. Ahí empieza el cambio.