Primer día de trabajo, llegas y te meten en una reunión para hacer la planificación, comienza la reunión y empiezan a hablar de S, M y L y lanzas la temida pregunta: “¿Aquí no se estima en horas?”, la gente te mira raro y alguien suelta la frase: “No, aquí no estimamos en horas, eso no es Agile”.
Si eres Agile Coach o Scrum Master es incluso peor, porque la frase la dices tú. Llegas a un equipo, te metes en su planificación, se disponen a estimar en horas y les cortas y les dices que tienen que dejar de pensar en tiempo y tienen que pensar en esfuerzo y complejidad, porque estimar en horas no es Agile.
En ambos casos siempre hay alguien que pone la cara mucho más rara y lanza la pregunta del millón:
“Si estamos utilizando Scrum, los sprints son de dos semanas y tenemos que decidir qué vamos a hacer en esas dos semanas, ¿cómo no vamos a pensar en tiempo?”
La pregunta es ¿por qué hemos demonizado las horas? y creo que la respuesta es clara: las horas son un elemento de control, nos recuerdan que todavía nos valoran porque estamos 8 horas sentados y no por el valor que generamos, y claro, eso sí que no es muy Agile. Además, en muchos equipos, la priorización cambia cuando conocemos las horas que nos va a llevar realizar una tarea (obviamos el valor que nos da y nos centramos mucho en el tiempo que nos va a llevar hacerlo). Pero seamos sinceros, esto va a ocurrir con cualquier modelo de estimación que usemos si no somos capaces de cambiar la percepción de que las tareas deberían valorarse por el valor que aportan y no por lo que lleva realizarlas.
Vale, además podemos sumarle a esta idea que, por norma general, los seres humanos somos muy malos estimando tareas en tiempo, pero cualquier tarea que realicemos, al final, nos va a llevar un tiempo concreto, por lo que eliminar completamente de la ecuación esta variable o demonizarla, personalmente, me parece un error.
Normalmente tendríamos que ayudar a nuestros equipos a que dejen de estimar completamente en horas y empiecen a tener en cuenta otros factores, pero nunca eliminándolo completamente. El problema de esa estimación en horas es que muchas veces lo hacemos pensando en que cuando nos vayamos a poner a hacer esa tarea, todo va a ser maravilloso, nadie nos va a molestar, no vamos a estar cansados de haber hecho otra tarea antes o directamente vamos a tener un mal día y nuestra cabeza no va a funcionar como funciona normalmente.
A mí me gusta que los equipos, a la hora de estimar, tengan en cuenta todas las variables, incluido el tiempo, y, aunque no utilicen directamente horas, sí que prefiero que no ignoren ese valor.
Normalmente cuando explico las estimaciones siempre pongo el mismo ejemplo:
Si las tareas de nuestros backlog consistiesen en lo siguiente:
- Correr una carrera de 10 km.
- Correr una media maratón (21 km.)
- Correr un maratón (42 km.)
Dependiendo de las personas que tengamos en el equipo, hablaremos de tiempos y esfuerzos completamente distintos. Existe la posibilidad de que a todos les lleve el mismo tiempo aplicando esfuerzos distintos y, si todos aplican el mismo esfuerzo, el tiempo sea completamente distinto. Pero al consenso que sí que podríamos llegar todos (hablando de tallas de camisetas) sería el siguiente:
- Correr una carrera de 10 km. sería una S
- Correr una media maratón (21 km.) sería una
M - Correr un maratón (42 km.) sería una L
Y si nuestro sprint fuese de una semana y el equipo decidiese que en dicho sprint pueden hacer una S, una M y una L; para mí, sería una buena planificación.
Pero si el equipo me diese una planificación de la siguiente manera:
- Correr una carrera de 10 km serían 2 horas +
6 horas para recuperar - Correr una media maratón serían 4 horas +
12 horas para recuperar - Correr un maratón serían 8 horas
También lo consideraría una buena planificación y ambas planificaciones serían igual de Agile.
Centrémonos en ayudar a los equipos a entregar el máximo valor posible y en ayudarles a mejorar sus planificaciones sacándolos de su día a día y ofreciéndoles distintos enfoques que les ayuden a mejorar continuamente (que esto sí que es ser Agile), independientemente de si realizan su planificación en horas o en perros (que no tiene nada que ver con ser Agile), al final, recordemos que son ellos los que deciden.
“Solo el Equipo de Desarrollo puede evaluar qué es capaz de lograr durante el Sprint que comienza.”
P.D.: Ya sé que el ejemplo no representa un proceso iterativo e incremental y que igual no tiene mucho sentido hacer algo así en Scrum, pero creo que ejemplifica bastante bien lo que quiero expresar
