Tiempo de lectura: 12 minutos

– ¿En cuántos puntos estimas que se puede hacer este ticket?

– Pues, no sé, depende… ¿cuentan mis puntos sólo? ¿los de QA juntos o aparte? ¿cuánto vale un punto? ¿quién soy? ¿de dónde vengo? ¿a dónde vamos? ¿por qué siguen sacando más temporadas de Cuéntame?

¿A alguien le suena esta escena? Vamos a intentar responder a la mayoría de preguntas, no todas, ya que algunas no tienen respuesta, o al menos no las tengo yo.

Un poco de contexto

Empecemos desde el principio… Dentro de las famosísimas Metodologías Ágiles se encuentra el megaconocido Scrum. Agile Scrum (que en inglés suena mejor) así, grosso modo, consiste en el desarrollo iterativo mediante pequeños Sprints, donde cada dos semanas (aproximadamente) se van haciendo una serie de entregas (nuevas funcionalidades de la aplicación o corrección de errores).

Cada una de estas funcionalidades (User Story) o correcciones de errores (Defect) están descritas en un ticket de Jirala herramienta por excelencia para la organización de proyectos ágiles (entre muchas otras cosas). Existen más tipos de tickets, realmente todos los que quieras según cómo se organice el proyecto, pero eso es otro tema a tratar, quiero centrarme en los dos principales y con los que mayormente he trabajado.

La estimación simplemente trata de dar un valor aproximado al trabajo/tiempo que requiere cada uno de estos tickets. De este modo es posible conocer la capacidad del equipo para cada Sprint, o al menos eso dice la leyenda. En teoría, tras una serie de Sprints, donde las estimaciones han ido mejorando con el tiempo y la experiencia, debería ser relativamente fácil saber la cantidad de puntos que es capaz de sacar adelante el equipo en cada Sprint.

En resumen:

  • Un proyecto agile se compone de una serie de sprints (Sprint A + Sprint B + … + Sprint Z)
  • Cada sprint tiene n‘ tickets (Ticket 1 + Ticket 2 + … + Ticket n)
  • Cada ticket tiene m‘ puntos

Para los matemáticos:

Sprint A: (Ticket 1 (m puntos) + Ticket 2 (m puntos) + ... + Ticket n (m puntos)) = x puntos

Donde ‘x’ es la capacidad que tiene el equipo cada Sprint.

Para los más matemáticos:

sumatorio

Nuestro objetivo es conseguir que el valor de ‘m’ (puntos de cada ticket) sea lo más realista posible, así podremos despejar ‘x’ (puntos de cada sprint),  que nos va a determinar el valor de ‘n’ (número de tickets de cada sprint) para cada Sprint. Dicho de otra forma, sabiendo cuántos puntos es capaz de sacar adelante mi equipo (‘x’) y estimando lo más acertadamente posible cada ticket (‘m’), soy capaz de saber cuántos tickets seré capaz de sacar adelante cada sprint (‘n’).

Una vez más, las matemáticas demuestran que se puede explicar algo muy sencillo de una manera muy compleja.

La realidad, como siempre, dista un poco más de la fantasía, pero con un poco de trabajo por parte de todos al menos se acerca al objetivo. Objetivo bastante difícil, si tenemos en cuenta que muchos proyectos suelen fracasar por una mala estimación.

Diferentes técnicas de estimación

Haber, hay muchas, pero yo os voy a contar las que he utilizado (prefiero hablar o, en este caso, escribir, con conocimiento de causa).

El valor de “un punto de historia”

> 1 punto = 1 hora

Hay poco que explicar de esta técnica, es bastante obvia: si crees que vas a tardar 3 horas, el ticket tiene 3 puntos de historia, fin.

Es la más fácil para los desarrolladores, el equipo de QA (Quality Assurance o Testing Manual) y demás a la hora de estimar.

Pero también es la menos realista para los Leads, ya que depende del tiempo y éste es una unidad muy relativa. Puedo estimar que voy a hacer una tarea en 3 horas y que  luego se caiga el entorno 2 horas, o que me atasque en algo que no había previsto 2 horas. E, imprevistos aparte, no siempre rendimos igual, a veces somos igual de productivos en 10 minutos que otras en 1 hora.

Por lo que, tras muchos tickets y muchos sprints, te puedes encontrar con que el Sprint 7 la capacidad de trabajo de tu equipo real (tickets que se ha cerrado durante ese Sprint) ha sido de 150 puntos de historia y que el Sprint 8 ha sido 300 puntos de historia… entonces, ¿cuál es la capacidad real de mi equipo?

> 1 punto = 1 jornada de trabajo

Al igual que la anterior, el nombre es bastante descriptivo, se trata de relativizar el esfuerzo de realizar una tarea en función de las jornadas de trabajo, ¿cuánto me llevará resolver este ticket? ¿1 jornada? ¿media? ¿1/4?

Y al igual que al anterior, tiene prácticamente las mismas ventajas e incovenientes ya que, al fin y al cabo, no deja de depender del tiempo, pues una jornada de trabajo no dejan de ser 8 horas, si dices que tardas una jornada es como decir que tardas 8 horas, si dices que tardas media, es como decir que tardas 4 horas, etc.

Si me lo permites, es como la anterior pero metiendo números fraccionarios y teniendo que hacer cuentas innecesarias de traslado a horas reales. Es más, ¿qué hay de esas jornadas que duran 9 o 10 horas? ¿o de los viernes que suelen durar menos que el resto de la semana? ¿Cómo podemos tener eso en cuenta a la hora de estimar? Este ticket te lo hago en una jornada larga y este otro te lo hago en una jornada de viernes…

> Escala de Fibonnaci

Archiconocida, archiamada y archiodiada, la secuencia de Fibonacci, para quien no tenga el placer de conocerla no la conozca, es una secuencia en la que cada número es la suma de los dos números anteriores, empezando con [0, 1], de modo que sería [0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, …].

Esta técnica usa los primeros números de la secuencia:

[1, 2, 3, 5, 8, 13, 21]

Aquí la teoría de la relatividad juega un papel muy importante, y no porque tome como factor determinante el tiempo, sino el esfuerzo y la complejidad. Para comenzar a estimar, primero, tiene que quedar muy claro cuál es el rango, ya que hay proyectos que usan hasta 21, otros que se quedan en 13. Vamos a suponer que nuestra escala es:

[1, 2, 3, 5, 8, 13]

El primer paso es coger todos los tickets del sprint a la vez, y ver cuál es el “más difícil” y cuál es el “más fácil”, de modo que al más fácil le asignamos el valor más bajo de la secuencia, 1, y al más difícil, el valor más alto, 13 en nuestro caso. Y así, vamos relativizando todos los tickets. Por ejemplo, imaginemos que tenemos una aplicación de “TO DO” y los siguientes tickets:

  • <TICKET_1> – Mostrar mensaje de confirmación al borrar un elemento → 1 punto
  • <TICKET_2> – Implementar un sistema de mensajería instantánea en la aplicación → 13 puntos
  • <TICKET_3> – Implementar añadir nuevo elemento → 8 puntos (definitivamente es más fácil que<TICKET_2>)
  • <TICKET_4> – Implementar borrar elemento → 3 puntos (es más fácil que<TICKET_3>, pero algo más difícil que<TICKET_6>)
  • <TICKET_5> – Implementar editar elemento → 3 puntos (mismo argumento que<TICKET_4>)
  • <TICKET_6> – Implementar borrar todos los elementos → 5 puntos (es más fácil que<TICKET_3>, pero más difícil que<TICKET_4> y<TICKET_5>)

Pero… ¿acaso la dificultad no es subjetiva? Lo que puede ser difícil para un perfil junior, puede ser sencillo para uno senior, o incluso para dos personas del mismo perfil, según experiencia puedes considerar que cierta tarea es más o menos difícil en comparación con otra persona. Entonces, ¿estamos en la misma situación que antes con respecto al tiempo? Pues vaya, Fibonacci es más difícil de aplicar y “tiene el mismo problema”.

Sabía que me dirías esto…

  • “¿acaso la dificultad no es subjetiva?” Pues no voy a ser yo quien no te diga que no (vamos, que sí, que lo es).
  • “¿estamos en la misma situación que antes con respecto al tiempo?” Pues sí voy a ser yo quien sí te diga que no (vamos, que no, que no es la misma).

Pero, razonemos un poquito, sólo un poquito. El problema de estimar dependiendo sólo y exclusivamente del tiempo es que no se tienen en cuenta factores que afectan al tiempo (por ejemplo, que se caiga el entorno durante 1 hora). Sin embargo, si consideramos que un ticket tiene 8 puntos de dificultad, los va a seguir teniendo igualmente aunque se caiga el entorno. Podemos tener 2 tickets estimados en 8 puntos y uno hacerse en 9 horas y otro en 5 horas, y ambos siguen teniendo 8 puntos de dificultad.

Por supuesto que el tiempo también se tiene en cuenta en la dificultad, no tiene sentido que estimemos un ticket de 3 puntos y se haga en 4 horas y otro de 3 puntos en media hora, lo mismo nos hemos equivocado con este último y debimos haberlo estimado en 1 punto.

¿Y si un ticket es muy fácil pero sé que me va a llevar mucho tiempo hacerlo, lo estimo en 1 punto?

Probablemente no. Dificultad y esfuerzo son la clave, puede que el ticket sea muy fácil, pero te va a suponer mucho esfuerzo hacerlo, por lo que 1 punto no sería una estimación muy acertada en este caso. Esfuerzo != tiempo, hay que tener mucho cuidado de no caer en puntos por hora, es una gran tentación.

“There’s a fine line between love and Fibonacci Scale”. Suena todo más difícil de lo que realmente es, pero una vez empiezas a aplicarla y a “cogerle el tranquillo”, pasas de odiarla a amarla.

Juntos pero no revueltos

Existen diferentes maneras de representar la estimación de los puntos de historia en un ticket.

> Estimación Total = Sum(Estimación parcial)

Los puntos de historia están divididos en el ticket, es decir, los puntos se dividen por equipo, por ejemplo en puntos de desarrollo, puntos de QA y puntos de QAA (Quality Assurance Automation o Testing Automático):

  • Story points → 9 puntos
    • DEV points → 5 puntos
    • QA points → 2 puntos
    • QAA points → 2 puntos

Si aplicamos Fibonacci, se aplica a cada estimación parcial, es decir, la suma total de las Story Points puede dar un número que no pertenezca a la escala de Fibonacci, por lo que juntar Fibonacci con estimación parcial no parece una pareja que vaya a tener mucho futuro, pues la gracia de Fibonacci es valorar el esfuerzo de cada ticket para saber cuántos tickets podemos sacar en cada sprint.

Sin embargo, para las otras técnicas de estimación dependientes del tiempo no supone ningún problema, la estimación parcial y ellas sí podrían tener una bonita relación a largo plazo.

> Estimación conjunta

Los puntos de historia no están divididos, el ticket tiene ‘m’ puntos de historia en total, para todos los equipos, siguiendo el ejemplo anterior, sería para desarrollar, para QA y para QAA.

  • Story points → 8 puntos

¿Y cómo se hace esto? Porque yo soy DEV, no puedo estimar por un QA.

“¿Y quimi si hizi isti? Pirqui yi si DIV, ni pidi istimir pir in QI”. Sigue leyendo, ansias.

¿Y quién estima?

> Los Lead

De entre todas las miles de reuniones o meetings que hay (o debería haber) en los proyectos agile scrum, está la 3amigos, donde BA (Business Analyst), DEV Lead y QA Lead se reúnen amistosamente, revisan y deciden los tickets que se incorporarán en el siguiente Sprint entre muchas otras cosas. Suena a un gran momento para estimar cada ticket y así ver cuántos entran en el Sprint.

A estas reuniones suelen ir los Leads, por lo que si el proyecto también cuenta con equipo de QAA, su Lead también podría ir, aportando éste la estimación de su equipo. Aquí es donde se puede hacer la estimación conjunta, en vez de por equipos, de modo que todos los Leads se ponen de acuerdo en el esfuerzo total que supondría sacar el ticket.

Lo “malo” es que para que esta estimación sea realista, los Leads tienen que conocer muy bien a su equipo, ya que muy probablemente un Lead estime que las cosas son más fáciles o se hacen en menos tiempo de lo que lo estimaría alguien del equipo (no-Lead).

> Uno para todos y todos para uno

Los puntos no tienen porqué decidirse siempre en la 3amigos meeting, ya que muchas veces ésta ni siquiera existe. En este caso, podemos optar por este método, en el que cada miembro del equipo da su estimación sobre cada ticket y después se llega a un acuerdo. Por ejemplo:

Hay que estimar el <TICKET_1> – Implementar funcionalidad ‘cosito’. El equipo lanza su estimación:

  • Pepe: 3 puntos
  • Ana: 2 puntos
  • Juan: 4 puntos
  • Lola: 5 puntos
  • Johnny: 1 punto
  • Laura: 3 puntos
  • Kevin: 3 puntos

A priori parece que Johnny es un máquina (o que no se ha leído el ticket), en cualquier caso, un aplauso para Johnny.

También parece que Lola es una pesimista empedernida. Lo más lógico sería que el ticket valiese 3 puntos, pero realmente lo ideal sería que cada cual argumentase sus puntos, sobre todo los que son más extremistas, lo mismo Lola ha visto alguna dificultad en la que no ha caído el resto, o lo mismo Johnny tiene un as bajo la manga que también desconoce el resto. Cuando todos están de acuerdo en una puntuación justificada del ticket, ésa es la que se pone.

> Ni contigo ni sin ti tienen mis puntos remedio

Por lo general, antes del siguiente Sprint ya hay más o menos una previsión de los tickets que van a entrar. Usando esta metodología, cada Lead los pasa al equipo, donde cada cual estima individualmente todos los tickets; luego se ponen en conjunto dentro del propio equipo y se llega a un consenso, y con esta estimación ya hecha va el Lead a la 3amigos meeting donde puede permanecer la estimación ya hecha o variar ligeramente.

Ejemplo:

  • Previsión de tickets para el próximo Sprint:
    • <TICKET_A> – Arreglar ‘cosito_1’
    • <TICKET_B> – Implementar ‘cosito_2’
    • <TICKET_C> – Implementar ‘cosito_3’
  • Estimaciones del equipo de DEVs
    • Juan: A – 3 puntos, B – 2 puntos, C – 5 puntos
    • Carmen: A – 3 puntos, B – 1 punto, C – 5 puntos
  • El equipo de DEVs llega a un consenso:
    • A – 3 puntos, B – 2 puntos, C – 5 puntos
  • El DEV Lead va a la 3amigos meeting, donde deciden que los 3 tickets entrarán en el siguiente sprint y al final las estimaciones son:
    • A – 3 puntos, B – 1 punto, C – 5 puntos

También, si no hay 3amigos meeting, es una opción perfectamente válida llegar a un consenso con los Leads, es decir, una vez que el equipo ha llegado a un acuerdo en los puntos, se pone en común con el correspondiente Lead.

And the winner is… 🏆

¡La que mejor se adapte a tu proyecto y equipo!

Creo que por mucho que Fibonacci sea la que da una estimación más realista, de nada vale ponerla en práctica en un equipo que no ha estimado nunca, creo que es una técnica a aplicar cuando se tiene cierto rodaje, tanto con el proyecto como con la capacidad de saber estimar cuánto nos va a suponer realizar cierta tarea.

Y, por mucho que lo mejor sea estimar primero por separado y luego ponerlo en conjunto, tener una reunión, llegar a un acuerdo, etc., las características del proyecto, o incluso del sprint, no siempre permiten invertir todo ese tiempo sólo en la estimación, a veces tendrá que estimar el Lead solo, a veces el Lead no podrá y será entre todo el equipo, o a veces incluso una persona del equipo únicamente.

Si ponemos en combinatoria todas las técnicas que hemos visto en el post, el resultado son muchas formas diferentes de realizar el proceso completo de estimación de los tickets, y esto sería tan solo aplicando los métodos que he explicado aquí, pero existen muchos más, por lo que las posibilidades se disparan exponencialmente. Por eso, una vez más, elige la mezcla explosiva que creas que mejor puede venir a tu proyecto y a tu equipo, adáptala, mejórala, cámbiala si no funciona.

Al final, el sentido común, aunque sea el menos común de los sentidos, es el que más hay que aplicar. Además, agile precisamente defiende la flexibilidad, no hay que tomar todo a rajatabla, sino partiendo de los principios, aplicarlos en la medida de lo posible a nuestras necesidades. Así, por ejemplo, si nuestro proyecto no tiene equipo de QA, ni de QAA, está claro que la estimación va a ser siempre conjunta, no se trata de forzar a dividir el ticket en el tiempo/esfuerzo que vas a dedicar a cada parte.

Conclusiones

Las técnicas dependientes del tiempo son mucho más fáciles de aplicar pero también son peores “futurólogas”, pues acabarás encontrándote con que un Sprint tu equipo ha sacado 300 horas y al siguiente ha sacado 150  horas, como dije antes.

Fibonacci es la más difícil, y la que tiene una mayor “curva de aprendizaje”, pero una vez superada la curva, es la que te da una estimación más realista.

“Cuatro ojos ven más que dos y también estiman mejor”, el final del refrán que nunca te contaron, pero es así, cuanta más gente participe en la estimación, mejor será esta. Como siempre, en la medida de lo posible y que el proyecto y el tiempo lo permita.

Dicen que el desarrollador es optimista por naturaleza. Mi consejo es que, apliques la ténica que apliques, si tienes duda, quédate siempre con la estimación más alta. Por ejemplo, en fibonacci, si dudas entre si la dificultad de un ticket es 3 o 5, pon 5 puntos; en tiempo, si dudas entre si vas a tardar 1 o 2 horas en realizar un ticket, opta por darle 2 puntos de historia (al final tardarás 5 horas, con suerte).

Mi opinión/recomendación/llámalo x (si te gustan las mates), es que si estás empezando, quizás sea más fácil empezar a estimar por horas, y una vez el equipo ha cogido soltura a la hora de estimar cuánto tiempo cree que le va a llevar hacer cierta tarea (algo que suena mucho más fácil de lo que es), entonces pasaría a Fibonacci. Tu equipo te odiará los primeros Sprints, pero una vez pasada esa curva, verás la luz y unas estimaciones que te timan un poco menos, pero nunca a propósito, y con cariño, siempre con cariño.

Pero lo dicho, sentido común, si se pasa a Fibonacci y la cosa no funciona tras varios Sprints, no hay que forzarlo tampoco; o lo mismo tu equipo es una máquina estimando en tiempo y acierta lo suficiente como para que te hagas una idea de la capacidad del mismo; o lo mismo has dado con la técnica infalible de estimaciones y yo estoy aquí dándote la chapa con Fibonacci.

Verónica Ojeda

Software Developer @ Gloin - También intento ver todas las series que me recomiendan, leo millones de artículos (desde tecnología, hasta recetas semisanas, pasando por muchos DIY), y por último, pero no menos importante, viajo más de lo que puedo y menos de lo que debo.

Deja un comentario