Ilustración Estimaciones Relativas

Una de las labores que se realizan en los equipos Agile para poder medir el esfuerzo y la complejidad de las historias de usuario, y en la que está involucrado todo el equipo, es el ejercicio de estimación.

Muchos equipos hacen uso de técnicas como planning póker, que nos ayudan a estimar de forma eficiente pero, ¿sabemos realmente cuál es el origen de la mejor forma de estimar? ¿Estamos cansados de dar estimaciones en tiempo que luego no se cumplen? ¿Tenemos a los jefes cabreados porque nuestro nivel de compromiso cumplido en cada sprint es muy variable? ¿Creemos que tenemos métricas de entrega de valor en nuestros equipos que se desvían demasiado de la realidad? Todas estas preguntas acaban respondiéndose cuando entendemos cuáles son las bases de una buena estimación.

Para poder estimar una HU de forma correcta, lo primero que tenemos que hacer es preguntarnos una serie de cuestiones (que son parte del Definition of Ready). Las más comunes suelen ser:

  1. ¿La HU cumple en la medida de lo posible el principio INVEST? (https://www.ingtechit.es/jdiegoreyes/por-que-es-tan-importante-definir-una-buena-historia-de-usuario-parte-ii/).
  2. ¿Sabemos qué funcionalidad estamos cubriendo y cuál estamos dejando fuera de la HU? ¿Se han solucionado todas las dudas (técnicas y funcionales) de la HU?
  3. ¿Los criterios de aceptación se entienden por el equipo y cubren todos los posibles escenarios?
  4. ¿Tenemos incertidumbre en el desarrollo de la misma? ¿La tenemos identificada?

El cumplimiento de los criterios anteriores nos va a facilitar mucho el poder estimar la HU ya que, al existir la mínima incertidumbre posible, la probabilidad de que nos encontremos con alguna sorpresa durante el desarrollo que haga que la estimación cambie será también mínima.

¿Pensar en tiempo?

Cuando pasamos por equipos, la mayoría de veces nos encontramos que el equipo estima en tiempo, y se producen conversaciones como… “Estimo que este evolutivo lo tienes en 5 días” ó “Esto es sencillo, en 4 horas lo tienes”.

Aunque tenemos que elegir una medida para estimar nuestras historias de usuario, el tiempo no suele ser la mejor de ellas, y esto se debe, entre otras cosas, porque estamos en un modelo de input/output variable.

Mejor lo vemos con un ejemplo:

Supongamos que estamos trabajando en una fábrica de tornillos. Basados en nuestra cadena de producción, somos capaces de generar 500 tornillos al día y cuando estamos en sobreproducción, hasta 750 al día.

Tenemos métricas de input / output exactos:

  • Producción normal = 500 / día.
  • Sobreproducción = 750 / día.

Ilustración Estimaciones Relativas 2

Por lo tanto somos capaces de dar una estimación en tiempo medianamente razonable, y somos capaces de predecir cuántos tornillos haremos al mes (suponemos que nuestra fábrica está produciendo 24×7):

  • Producción normal = (500/día)*31 = 15500 tornillos al mes.
  • Sobreproducción = (750/día)*31 = 23250 tornillos al mes.

El desarrollo software no es una ciencia exacta, sino un arte creativo y totalmente cambiante, de hecho, uno de los principales problemas que nos encontramos midiendo algo en el mundo del software es que tan pronto lo estás midiendo ya está cambiando; las tecnologías cambian, las arquitecturas emergen, los requisitos del cliente cambian durante el desarrollo. Sabes que el diseño y el código de hoy no será el mismo que el de mañana.

Dar una estimación en tiempo no te asegura que la historia de usuario que estás abordando tarde exactamente ese tiempo porque hay muchas variables que te van a modificar tu estimación inicial, así que habrá un alto porcentaje de probabilidad que tu estimación no sea exacta.Ilustración Estimaciones Relativas 3

Por muy maduro que sea un equipo en las tecnologías en las que está trabajando, y la experiencia que tenga en anteriores proyectos, sabemos que la naturaleza del software es cambiante, por lo que esto afecta a todos los equipos de desarrollo, independientemente del nivel de expertise que posean.

Pero hay una cosa que sí se nos da bien: comparar. Sabemos decir si una tarea lleva más tiempo, es más complejo o conlleva más esfuerzo realizarla que otra. Lo vemos a continuación.

Estimar de forma relativa

Basado en el artículo The Main Benefit of Story Points, suponemos la situación:

Se pregunta a dos corredores: “¿Cuánto se tarda en correr 10km?”

  1. El primero, corredor experimentado, te va a responder: “40 minutos”
  2. El segundo, corredor principiante, te va a responder: “1h como mínimo”

Ambos tienen razón, pero difieren en sus ‘estimaciones’. Lo único que está ocurriendo es aquí que lo están viendo desde su perspectiva, aunque ambos están de acuerdo que la distancia que hay que recorrer son 10km. En ese objetivo de 10km es en el que nos tenemos que centrar, y la velocidad la obtendremos como consecuencia de estimar de forma relativa.

Los puntos de historia lo que buscan en realidad es disponer de una medida relativa que permita comparar historias de usuario en base a su esfuerzo (cantidad de tareas conocidas que es necesario abordar) y complejidad (dificultad técnica, tareas de investigación, etc.), de tal forma que tener una HU “A” de 5 puntos y otra HU “B” de 3 significa que A es más compleja y tiene más esfuerzo que B.

Métricas y herramientas

Para conseguir poder estimar de forma relativa, podemos hacer uso de algunas métricas/herramientas que nos ayuden.

Hay varias métricas que podemos usar para medir de forma relativa. Las más usadas suelen ser:

  1. Tallas: Tallamos nuestras historias de usuario como XS, S, M, L, XL, XXL, que nos permitan dar un tamaño relativo de HU.
  2. Serie de Fibonacci: Ésta es la más recomendada, ya que a medida que aumenta nuestra incertidumbre, el valor de la medida relativa (en puntos historia) aumenta en distancia con el anterior: 1, 2, 3, 5, 8…

Más información sobre puntos historia y qué beneficios nos ofrece: https://www.mountaingoatsoftware.com/blog/what-are-story-points.

En cuanto a herramientas, destaco una que realmente nos ayuda sobre todo a introducirnos en el ejercicio de estimación relativa en el equipo: la matriz de estimaciones relativas.

Se suele introducir en la sesión de sprint planning una o varias veces, hasta que el equipo obtenga una madurez que les permita obviar este ejercicio, y usar otros como planning poker.

Tenemos una matriz 3×3 cuyo eje de ordenadas corresponde al esfuerzo de la HU (de menor a mayor esfuerzo) y el eje de abscisas corresponde a la complejidad de la HU (de menor a mayor complejidad). Estas van a ser las métricas que vamos a usar para comparar nuestras HU del sprint. Recordemos que el esfuerzo consiste en el desarrollo de aquellas tareas identificadas en la HU y que es necesario abordar, y la complejidad corresponde a la dificultad técnica (piezas arquitectónicas, integraciones con otros componentes, etc.) e incluso si la HU añade cierta incertidumbre.

El ejercicio es el siguiente:
Ilustración Estimaciones Relativas 4

  1. Cogemos por ejemplo la HU “A”, la más prioritaria en nuestro product backlog.
  2. Realizamos la pregunta: “¿Qué medida de esfuerzo (bajo, medio o alto) conlleva la HU?”
  3. Realizamos la pregunta: “¿Qué medida de complejidad (baja, media o alta) conlleva la HU?”
  4. Situamos dicha HU “A” por ejemplo en la casilla “Esfuerzo medio”/”Complejidad media” (en el centro de la matriz)
  5. Repetimos los pasos 1-3 con la siguiente HU “B”.
  6. Comparamos “B” con las historias de usuario de la matriz (actualmente sólo “A”), y preguntamos: “¿B tiene más esfuerzo que A?” y “¿B es más compleja que A?”).
  7. Si nos sale que tiene más esfuerzo, pondremos “B” más arriba que “A”.
  8. Si nos sale que tiene más complejidad, pondremos “B” más a la derecha que “A”.
  9. Puede ser que ambas tengan el mismo esfuerzo y la misma complejidad, por lo que situaremos “B” en mitad de la matriz junto a “A”.
  10. Si ahora cogemos la siguiente HU más prioritaria en nuestro product backlog, “C”, realizamos el mismo ejercicio anterior, haciéndonos las preguntas: “¿C tiene más complejidad/esfuerzo que A? ¿Y que B?”.
  11. Continuamos añadiendo HUs hasta que creamos que hemos añadido suficientes historias a nuestro sprint. ¿Y esto es a ojo? Sí, pero sólo nos ocurrirá en la primera iteración con estimaciones relativas, ya que luego nos basaremos en la velocidad del equipo que hayamos obtenido en el primer sprint (más adelante explicaré el concepto de velocidad de equipo).

Es posible que al introducir una nueva HU a la matriz, el resto tenga que reajustarse y posiblemente moverse de casilla, para encajar todo en la misma. El objetivo es que al final del ejercicio, el equipo tenga una foto del grado de complejidad / esfuerzo de las HUs del sprint.

A continuación trazaremos diagonales a la matriz, y estableceremos los puntos historia correspondiente a las HU que estén dentro de las casillas que cruza la diagonal:

Ilustración Estimaciones Relativas 4

Tendremos por tanto:

  1. 0 HU con 1 punto/historia.
  2. 2 HUs con 2 puntos/historia.
  3. 5 HUs con 3 puntos/historia.
  4. 0 HU con 5 puntos/historia.
  5. 1 HU con 8 puntos/historia.

Si hay HUs que tienen tanto esfuerzo y tanta complejidad que quedan fuera de la matriz, es bastante probable que tengan que ser divididas en varias HU.

Si tenemos spikes / chores o cualquier otra tarea que el equipo no estime, no es necesario incluirlas en la matriz, aunque sí las contaremos para el esfuerzo total del sprint.

Podéis seguir más artículos, noticias y datos interesantes en https://www.ingtechit.es y en mi cuenta de Twitter.