Sin duda, a todos nos han pedido o pedirán estimar una tarea en algún momento. Naturalmente, el siguiente pensamiento que nos llega a la cabeza es estimar horas -Al fin y al cabo, todos sabemos cuánto tarda algo, es una medida que usamos todos los humanos en el día a día.
Sin embargo, en desarrollo de software, estimar en horas quizás no sea lo mejor.
El problema de las horas
Hace algunos años desarrollé aplicaciones para una empresa X. En mi equipo de trabajo estábamos una mujer a quien voy a llamar "María", un hombre a quien voy a llamar "Juan" y yo. María era una desarrolladora iOS Senior súper veloz y brillante, tenía muchos años de experiencia y su trabajo era de alta calidad. Juan y yo eramos solo un par de desarrolladores Junior.
Nos pidieron estimar cuánto tiempo nos tomaría hacer cierta funcionalidad, así que nos reunimos una tarde entera para hacerlo. Consideremos una tarea A. Para Juan y para mi, esta tarea era relativamente compleja: nos demoraríamos unas 4-6 horas en terminarla. En cambio, para María, la tarea era muy fácil: tal vez se demoraría entre 1 y 2 horas.
¿Quién tenía la razón? ¿Cuál era la estimación correcta? ¿Usamos la estimación del que va a hacer la tarea? ¿Y si no sabemos quién va a tomar el ticket?
Al promediar sentía que me estaba poniendo la soga al cuello: Inicialmente había estimado que me demoraría seis horas, pero ahora debo comprometerme a terminar este ticket en tres.
Además, cuando ya estaba desarrollando la tarea, si el promedio era tres horas y no la había terminado en ese tiempo, sentía una presión muy desagradable: ¿No era lo suficientemente bueno como para terminar en tres horas? ¿Esto va a tomarse como un problema de rendimiento a la luz de mis superiores? Sentía que estaba fallando cada vez que decía que aún no había terminado.
¿Que mide un story point?
Los story points no miden tiempo sino esfuerzo relativo y complejidad (y algo más que veremos en la siguiente sección).
Cuando estimamos que una tarea tiene 5 puntos, en realidad nos referimos a que es cinco veces más compleja que una de 1 punto.
Esto hace que la estimación sea un poco más independiente de quién la va a hacer y facilita llegar a un consenso.
Story points como medida de incertidumbre
Antes dije que usar story points facilita llegar a un consenso. Elaboremos un poco más esta idea: ¿Qué pasaría si yo estimo que una tarea toma 3 puntos y María dice toma 2 puntos? ¿Calculamos el promedio entre los dos? ¿Nos quedamos con el menor o el mayor?
Además de representar esfuerzo relativo y complejidad, los story points también son una medida de incertidumbre: Entre más grande sea una tarea, más incertidumbre se tiene.
Por esta razón, creo que lo mejor es buscar un consenso donde todos estén de acuerdo en cuánta incertidumbre hay. Si María y yo discutimos si poner 2 o 3 puntos a una tarea, quizás sea buena preguntarnos cuánta incertidumbre hay en la ejecución de la tarea. ¿Tenemos claro como hacerlo? Podemos dejar 2 ¿Todavía hay dudas? Tal vez podamos dejar 3. Al fin y al cabo ¿qué nos detiene a refinar la estimación después? - Hablaremos de esto más adelante.
Estrategias para estimar
Veamos algunas de las estrategias para estimar que conozco (seguro existen otras):
Tamaño de camisetas (T-shit sizing)
- En vez de números se usan tallas de camisetas: XS, S, M, L, XL, XXL.
- Es menos preciso pero más fácil de calibrar.
- Sirve cuando se tiene poca información sobre el dominio o el equipo es nuevo estimando.
- Se busca refinar a alto nivel sin entrar en detalles.
Potencias de dos
- Valores: 1, 2, 4, 8, 16
- Cada valor dobla al anterior para reflejar el aumento de incertidumbre
Fibonacci
- Valores: 1, 2, 3, 5, 8, 13
- Como el anterior, a medida que el valor aumenta, señala un incremento de incertidumbre
Estimación por puntos lineales
- Valores: [1 al 5] o [1 al 10]
- Es tentador usar esta escala cuando hay poca incertidumbre.
- Debido a la granularidad de la escala, se pierde más tiempo debatiendo si algo es un 6 o un 7.
Sprint de calibración
Después de estimar el esfuerzo de todas las tareas con story points, empiezan los sprints. Sin embargo, antes de empezar de lleno con el desarrollo, considero que es buena idea empezar con un "sprint 0" o de calibración, donde el equipo toma algunas tareas pequeñas y sencillas que antes se habían estimado como de nivel 1.
De ahí se puede corregir la estimación del resto de tareas con base en el esfuerzo real requerido para completar las de nivel 1.
En este punto es muy válido preguntar: ¿Debo reestimar absolutamente todas las tareas? ¿En qué momento lo hago?
Aunque quizás sí tiene sentido reestimar cualquier tarea que el equipo sienta que está muy desajustada con respecto a la nueva referencia, en realidad no es necesario reestimar todo de nuevo.
En lugar de ello, solo es necesario reestimar las tareas que están próximas a entrar al sprint y que se van a trabajar en las siguientes una o dos iteraciones. Este refinamiento del backlog se puede hacer al principio de la ceremonia de planning. No es necesario una reunión ad-hoc para esto, sino que se puede dedicar los primeros 15 minutos del planning y ajustar lo que haga falta.
En cuanto a las tareas que está muy abajo en el backlog, definitivamente es necesario reestimarlas porque, bajo una metodología ágil, es posible que haya cambios en el alcance al llegar a ellas. Reestimarlas al inicio puede ser trabajo perdido.
Velocidad del equipo
Después la calibración y reestimación de las tareas se puede calcular la velocidad DEL EQUIPO: ¿cuántos puntos promedio terminamos en un sprint?
Si tenemos una velocidad de 30 puntos por sprint, y tenemos un backlog con tareas estimadas, podemos proyectar aproximadamente cuántos sprints va a tomar entrar una funcionalidad grande.
Un arma de doble filo
Es muy tentador usar la métrica de story points terminados por sprint como medida de productividad individual, sin embargo, considero que no es buena idea.
Recuerdo que la misma empresa que mencioné antes podían decir cosas como que María había terminado 20 puntos en el sprint, mientras que Juan solo había logrado terminar 10 y por eso su rendimiento era bajo. Sin embargo, este tipo de juicios podría ignorar que las tareas son distintas, junto con su contexto. Además, los story points fueron una estimación del equipo, no del individuo.
Aunque no me siento orgulloso de ello, recuerdo que en su momento, algunos de los desarrolladores (yo incluido) empezamos a inflar las estimaciones para protegernos. Es ahí donde la herramienta de estimación con story points pierde utilidad.
Conclusión
Estimar es adivinar. No es una ciencia exacta. No obstante, la idea es hacerlo lo mejor posible para que el negocio se pueda hacer promesas de entrega del producto.
Si has llegado hasta aquí, ¿qué piensas sobre lo que dije? ¿Has usado story points? ¿O prefieres otro sistema de estimación? ¿Por qué?
Top comments (0)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.