Vamos con la segunda parte del post de ayer.
Me voy a saltar el debate de si hay que estimar, o no, del valor frente a la estimación, etc., para eso ya hay posts como ¿Tiene sentido estimar? Quizá no deberíamos estimar proyectos #NoEstimates explicado, este mis diapositivas sobre #NoEstimates o sobre que la estimación no sea la pieza central de un proyecto o este un proyecto ágil se guía por valor no por estimación (más sobre #noEstimates)). El contexto de hoy es que estimas Historias de Usuario (extensible, con cuidado, a Items) usando Puntos Historia.
La curva de Rayleigh, como vimos en el anterior post, es un clásico (poco conocido para la mayoría, cierto) en el mundo de la estimación, y viene de la época pre-ágil (lo de «pre» refiere a popularidad, no tanto a origen, Agilidad… ¿Algo novedoso? ¿Estás seguro?), como también vimos en el post de ayer. Yo había leído sobre ella hace años, al menos, como poco tengo unas diapos del 2005 donde hablaba de estimación y ya metí la curva de Rayleigh.
En 2005, por poner el año del ppt que te mencioné en el post previo a este, ya hacíamos «cosas» ágiles (La ppt, la presentación, de mi primer proyecto Agil (ojo, del 2001) pero… no teníamos tantos datos, experiencias, etc., lógicamente, como las que puedo tener a fecha de hoy.
El caso, y lo curioso (o no tanto, porque tiene su sentido), es que después de ver muchas estimaciones ágiles (de las que me encuentro con datos y cierto histórico), además de las mías propias, un día me di cuenta de que, también, seguían la curva de Rayleigh.
Pongámonos en antecedentes, cuando, independientemente de la interpretación que le des (aquí no me extiendo o no acabo el post y me salen 3 partes más, para ampliar esto léete la guía de estimación), asignáis un determinado Punto Historia a una Historia de Usuario (o Item), le dais un 1, o un 2, un 3, 5, o el que sea, hay una relación, seas consciente o no, no-lineal entre esa estimación que le has dado y el tiempo que realmente se tarda en completar esa Historia de Usuario.
Y, por lo que yo he visto (y no soy el único, ni mucho menos un descubridor, hay gente que ya lo había visto antes)… sigue la curva de Rayleigh.
Obviamente, a mucha menor escala que como vimos ayer, cuando te conté lo de Norden, los efectos, la probabilidad de estimar (asignar un Punto Historia) y que la realidad sea menor o mayor (lo que vimos también ayer) tienden a seguir una curva de Rayleigh con algunas interesantes matizaciones que te interesa entender.
La relación no-lineal Punto Historia tiempo
Aunque no seas consciente (puedes vivir bien sin serlo), si todo es normal (no hay micro cascadas), y si llevas ya tiempo en esto, cada vez que asignas un Punto Historia, la mayoría de las veces (la mayor probabilidad) todas esas Historias que tienen los mismos Puntos Historia… se acaban terminando en un rango de tiempo (un mínimo – máximo) similar. Ese rango es, obviamente, diferente cuando se asigna otro número de Puntos Historia.
Por ejemplo, todas las Historias a las que se les asigna un 5, suelen resolverse entre 4 días y 6. Las de 10, entre 6 y 14, etc. Si tienes datos históricos, y lo haces más o menos bien (sino haces, por ejemplo, micro cascadas en un Sprint), esto lo has tenido que ver, o lo puedes observar.
La probabilidad que hay de que asignado un determinado número de Puntos Historia, la realidad sea INFERIOR a lo estimado…
Es decir, pongamos que a un Item le damos, por ejemplo, 5 Puntos Historia, y que, históricamente, ese tipo de Historias se resuelven entre 4 y 6 días. Entre 4 y 6 días sería lo normal, pero aquí aparece la dichosa curva de Rayleigh, porque hay probabilidad de que las resolvamos en tiempo «anormalmente» (no es lo usual) menor, por ejemplo, 3, aunque esa probabilidad es baja, y es cada vez más baja (mírate la parte izquierda de la curva del dibujo de ayer).
Y es probabilidad cero el poder bajar de un umbral, lo cuál es lógico, no voy a tener Historias que se resuelvan en 0 días, ni que se acerquen a cero por añadir más gente (esto yo sé que tu lo sabes, pero aún hay mucho manager del Lado Oscuro que me saca este tema, y ya te cité a Brooks en el post anterior, en relación a esto).
La probabilidad que hay de que asignado un determinado número de Puntos Historia, la realidad sea SUPERIOR a lo estimado…
Vamos con el otro caso, un Item al que le damos, por ejemplo, 5 Puntos Historia, como en el caso anterior, que, históricamente, ese tipo de Historias se resuelven entre 4 y 6 días. De nuevo, aparece la curva de Rayleigh: hay probabilidad de que las resolvamos en tiempo «anormalmente» (no es lo típico) superior, por ejemplo, 10, aunque esa probabilidad es baja existe, habiendo probabilidad de temporalidades reales más altas y hasta infinito (no terminar nunca), aunque sean cada vez menores.
A mayores Puntos Historia asignados baja la probabilidad de acertar es menor, y crece el rango mínimo-máximo real en el que te mueves
Pero ojo, y esto es importante para el día a día, las curvas de Rayleigh cuando asignáis 1 puntos historia no son las mismas que cuando asignáis 21.
La probabilidad de acertar cuando asigno un 1 es mucho mayor que cuando asigno un 21 y la realidad mínima – máxima en la que se mueven los 1 es más pequeña que la de los 21.
Terminando y para qué te vale a ti todo esto
Conclusión de esto… estimaciones en Puntos Historia grandes son peligrosas, son menos estables, tienen más oscilación.
Segunda conclusión de esto, obvia, hay que tener estimaciones en Punto Historia lo más pequeñas posibles.
Tercera derivada, para ello la solución más obvia es tener Historias lo más pequeñas posibles, otra de tantas razones más para que os fijéis el objetivo de qué las Historias de Usuario deben ser lo más pequeñas posible. Y digo que esto es obvio pero sé que para muchos es muy difícil por el «Legacy», pero no relajéis este objetivo.
Cuarta, si, después de todo lo anterior, llegas a tener Historias de Usuario lo más pequeñas, es muy probable que todas sean iguales, si todas son más o menos iguales, imaginemos, que todas tendrían «2 Puntos historia», en ese punto… no te merece la pena estimar usando Puntos Historia, llegarás al Karma de la estimación y lo harás en «número de Historias» (pasando del Punto Historia), tu velocidad y consecuentes estimaciones serán en función de ello (aunque Rayleigh se te seguirá manifestando y apareciendo de vez en cuando). De hecho, viendo esto, el Punto Historia es un «apaño» para resolver que las Historias no son todas igual de grandes.
Advertencia, no te rayes con todo esto y te pongas con la mayor arma de destrucción masiva que ha creado al humanidad, peor aún que la Estrella de La Muerte… el Excel, a meter datos y tal. No merece la pena, no añadas desperdicio, etc. No obstante, no está demás que interiorices lo anterior y que estés atento a cómo se mueven tus estimaciones.
Si tienes datos históricos y te apetece, no tengo ningún problema en echarles un vistazo y darte mi opinión, en privado o público, como quieras, ya sabes cómo localizarme.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
La presentación me parece brutal! un gran resumen de la naturaleza del desarrallo de software.
Cuanta falta hace que los departamentos de calidad de software se lleven de canas, se debería exgir un mínimo de años de codifidicación, diseño y pruebas de software