«La propia palabra ‘estimación’ deja en claro que no calculamos un valor exacto,
determinístico. De hecho, toda estimación tiene supuestos, y estos supuestos suman
incertidumbres.» – Carlos Fontela, Estimaciones y Estadística, CyS Ingeniería de Software (2007)
Los más experimentados en agilismo leerán el título de este post y dirán: «¿y todavía hay dudas sobre esto?», posiblemente llevarán su cursor hacia la X y cerrarán la ventana. Pues, cuando comienzas una jornada de adopción hacia el mundo de Agile y Scrum con muchas personas que lo están aprendiendo y tratando de hacer match de los conceptos y prácticas sobre la forma tradicional, existen muchas preguntas que considerarías básicas; pero desde mi perspectiva son muy importantes, y pienso muy bien en las respuestas que daré. La importancia radica en que las prácticas, técnicas y artefactos del agilismo reflejan un mindset cuyos valores y principios deben ser comprendidos para encontrar el significado y el beneficio de usarlos; del por qué de la práctica, del por qué es diferente y en qué sentido.
La persona quien me hizo la pregunta había realizado la tarea y me muestra un artículo de Mike Cohn que titula: «Story Points are still about Effort». Y me escribe un párrafo por mail destacando lo que considera lo más relevante de la lectura:
«En el caso de los story points, se estima el esfuerzo (tiempo) para hacer una cosa – ese esfuerzo puede verse afectado por el riesgo, la incertidumbre o complejidad. Así que permítanme decir tan claramente como puedo: los story points son una estimación del esfuerzo, no de la complejidad.» – Mike Cohn
A línea seguida me escribe diciendo: «Tengo serias dudas de qué realmente es un story point: Complejidad o esfuerzo o tiempo?. Cuando le digo al Gerente de Proyecto que tenemos una desviación de 10 puntos frente a lo planeado, él me pregunta: con cuánta gente y en qué tiempo podemos resolverlo?. No sé qué responder.»
Adicional a esto, puedo agregarle un componente importante de mencionar. Siguiendo el marco de trabajo usado para la adopción en la compañía, en algún momento se dio por sentado en que existe una relación de conversión de Story Points a Horas, básicamente 1 Story Point = 1 día = 8 horas. De tal forma, aritméticamente se puede establecer una traducción que puede simplificar la comprensión de los story points y solucionar el problema mencionado.
Bueno, ahora me toca responder; y pensaba que hacer una precisiones primero.
1. Esfuerzo no es exactamente una unidad tiempo
El esfuerzo es una relación entre la cantidad de tiempo que requiere realizar una tarea en función de un número personas que la van a trabajar, y tradicionalmente se la expresa en personas-horas u horas-hombre o personas-mes. Básicamente, el esfuerzo relaciona tres dimensiones, tiempo, número de personas y la disponibilidad de éstas. De esta forma, si tradicionalmente estimamos una tarea que toma 8 horas para una persona (8 horas-hombre), y agregamos otra persona al 100% de disponibilidad, la tarea se terminaría en 4 horas aproximadamente. En los métodos tradicionales existen varias técnicas para la estimación de esfuerzo y a partir de este los costos: Cocomo, Puntos de función, Puntos de Casos de Uso, Putnam, Juicio experto, Delphi, etc. Todas expresan una relación entre tiempo y número de personas. Esfuerzo no significa tiempo a secas.
2. No existe una relación lineal de Story Points a Horas
Esto es algo que percibo ya en varias adopciones. Siento que existe una necesidad de poder expresar los puntos de historia en un lenguaje más conocido, como las horas-hombre. Algunas personas me dicen que es porque el Cliente así lo exige. En algunas ocasiones, he visto que se estiman las Features en Horas-Hombre y luego se las traduce a Story Points para establecer el número de equipos necesarios en base a su velocidad. Lo cierto es que esto no es posible hacerlo de esta forma y cualquier fórmula que nos creemos nunca nos dará una equivalencia real válida.
El problema con establecer los story points como tiempo es, que las personas tienden a generar una relación automática entre story points y horas; favoreciendo el pensar en horas gracias a la forma tradicional de estimación que nos solicitaban en el pasado. Por ejemplo, establezcamos una relación de 1 story point = 8 horas, como lo menciona SAFe. Cuando se le pide a un miembro del equipo estimar una historia, automáticamente está pensando en «¿cuánto tiempo me tardaré?», por varios factores agregan normalmente un buffer o colchón; y dicho valor lo dividen para hacer la equivalencia en puntos. «Okay, creo que me tardo 2 días, pero por si acaso voy a decir 3 días…en puntos significan 3 story points.».
Es volver a la pregunta: «¿cuánto te tardas en realizar esta tarea?», en lugar de «qué tan compleja consideras esta tarea con las condiciones dadas frente a esta otra historia de referencia ?».
Mike Cohn escribe un artículo posterior al mencionado arriba describiendo el problema y que básicamente al actuar así se pierden los beneficios de los story points, Don’t Equate Story Points to Hours:
«He sido bastante inflexible últimamente en que los puntos de historia son sobre el tiempo, específicamente esfuerzo. Pero eso no significa que usted debe decir algo así como: ‘Un punto de la historia = ocho horas.’ » – Mike Cohn
3. Un Story Point es una herramienta de Colaboración
Un Story Point es una medida que engloba: complejidad (inherente y accidental), tamaño, incertidumbre y habilidad/conocimiento sobre el problema planteado (ojo: tamaño y complejidad no son lo mismo).
En otras palabras un Story Point es la medida de esfuerzo mediante la cual un equipo evalúa la complejidad, el tamaño, el nivel de incertidumbre y el riesgo de realizar una historia en base a las destrezas, conocimiento y la información actual que poseen los miembros que conforman ese equipo, entendiendo que esfuerzo no es igual a tiempo.
Debido a la evaluación personal de estas dimensiones, una misma historia puede ser 1 punto para una persona y 8 para otra; un equipo experto trabajando mucho tiempo sobre el mismo módulo puede estimar una historia con un valor relativo menor que otro que nunca ha trabajado en ese módulo, y esto está bien. Los Story Points nos permiten realizar comparaciones relativas para establecer acuerdos sin importar el tiempo de resolución. La duración en tiempo para resolver la tarea es algo que se verá cuando se termine la tarea. Hay historias de 8 puntos que pueden ser terminadas en 2 días o en 4 días, pero para el equipo siguen siendo de 8 puntos, entonces no hay una relación lineal, la relación es una curva (como se muestra en este artículo http://www.targetprocess.com/articles/estimates-software-development.html).
Mi recomendación
En serio, no asocie un Story Point con tiempo. Puede generar disfunciones como: sobre-estimaciones, dificultad de llegar a consensos, dificultad en la comunicación del equipo, estimaciones basadas en tiempo como se hacía tradicionalmente, si lo toma María son 3 puntos, pero si lo toma Juan son 8, proliferación de fórmulas matemáticas de conversión, redondeos de los valores de la fórmula (ejemplo: si la fórmula nos entrega 8,6 el siguiente valor en Fibonacci es 13, entonces son 13 puntos), etc.
Al usar el story point “puro”, le ayudamos a pensar al equipo en la dificultad propia del problema a resolver, más no en el tiempo ni en quien lo debe resolver. El nivel de incertidumbre estará dado por la misma escala de Fibonacci evitando sobre-estimación para cubrirse, esto a la larga cambia el mindset el equipo enfocándose en la cantidad de complejidad que pueden abarcar en un sprint. La idea es que el equipo vaya afinando sus estimaciones tras cada iteración, el mismo equipo junto trabajando sobre el mismo dominio durante un tiempo.
Referencias
Para más información les dejo estos links:
http://www.infoq.com/news/2009/09/story-points-versus-hours
https://agilefaq.wordpress.com/2007/11/13/what-is-a-story-point/
http://www.mountaingoatsoftware.com/blog/dont-equate-story-points-to-hours
http://www.targetprocess.com/articles/estimates-software-development.html
http://tracer.lcc.uma.es/problems/estimation/estimation.html
http://es.slideshare.net/mstabare/gestion-de-proyectos-estimacin-del-esfuerzo
http://scaledagileframework.com/iteration-planning/
http://www.slideshare.net/JohnnyDark/estimacin-gil-story-points-y-planning-poker
Johnny Ordóñez 
Johnny:
Excelente tu enfoque. Quiero referirme a la apertura de tu post, sobre eso de que ‘Los más experimentados en agilismo leerán el título de este post y dirán: “¿y todavía hay dudas sobre esto?”, posiblemente llevarán su cursor hacia la X y cerrarán la ventana’. No deberías preocuparte mucho por eso: Pienso que si efectivamente los más experimentados cierran la ventana, en verdad no serán tan experimentados. Si tu enfoque nace de tu propia experiencia, siempre tendrá algo que enseñar, aun a los más expertos en el asunto.
Y a propósito de que mencionas a Mike Cohn, hace algunos días publicó un post del que yo mismo pensé, no por más experimentado, por cierto, sino precisamente pensando quizás en lo mismo que te llevó a ti a abrir de esa manera: ‘esta gente todavía discute este tema’ y pensé que siempre hay algo nuevo que aprender y que, por supuesto, siempre están los así llamados ‘noveles’ o ‘recién llegados’ al ecosistema ágil. El asunto del señor Cohn era sobre si Ágil necesita ser iterativo e incremental. ¿Qué hay más básico que eso? Es lo primero que cualquiera aprende sobre ello, pensé, pero también me dije a mí mismo: ‘mí mismo, si está aquí es porque hay algo nuevo bajo el sol, es porque hay gente que todavía no ha entendido, es porque todavía hay quien necesita conocerlo’. Finalmente lo contacté y le dije que quería traducir el artículo, está en mi Gazafatonario.
¡Yo me quedo con tu recomendación!
Salud@s, nos vemos en la red.
Lucho
Hola Lucho, mil gracias por el comentario y tu propuesta; voy a buscar el artículo en tu blog y lo compartiré también. Por qué comencé así? Puede que esté bien o mal, pero cuando a veces retomo estos temas «básicos» con agilistas, algunos como que sienten que ya conocen mucho del tema y sólo te mandan a leer un libro. Es verdad, capaz que sienten que ya conocemos todo de Story Points, no es mi caso. Pero yo siempre digo: no puede haber expertos en Agile, porque Agile representa aprendizaje continuo.
Nuevamente gracias amigo, te espero por Ecuador. Un abrazo!!
Interesante el artículo y de acuerdo en muchas cosas, sin embargo, nos olvidamos de lo realmente importante, el equipo y su cultura… podrá existir el sistema más perfecto pero debes empezar por casa, por uno mismo, si el equipo sigue asociando la estimación en horas-hombre, no resolverá en entregar o no a tiempo una historia. Y qué es lo que hace un líder? para mi punto de vista es muy importante conocer al equipo y saber de cada miembro sus fortalezas y debilidades, de tal manera que si es alguien que tiene un mayor nivel de experticia pueda ayudar a su compañero y tenga la habilidad de atreverse hacer un trabajo que usualmente no lo haría. Y también concuerdo que a la final vas a necesitar una métrica a nivel empresarial porque estas comprometido en la entrega de un producto, la idea es que con esta metodología se entregue un producto con mayor nivel de calidad y con un mayor alcance, porque si seguimos con proyectos retrasados y sin calidad, a la final al empresario le pagan por el producto final y que se encuentre en el tiempo que de antemano te pudieron hasta imponer. Y también quiero la presentación para Gerentes de Proyectos, etc.
Hola Sandrita, muchas gracias por tu comentario. Totalmente de acuerdo contigo, y fue algo que no puse inicialmente en el post (aunque lo pensé, pero no quería alargarlo). La pregunta inicial refleja que todavía se mantiene un mindset tradicional sobre el manejo de los proyectos y su progreso. Hay que seguir caminando hacia la interiorización de los valores y principios. Subiré mi presentación y te paso el link.
Gracias, un abrazo.
Debo decir…a mi pesar que sigo sin entender… 😞
Historia corta: Puntos de Historia de usuario son una herramienta que usan algunos equipos ágiles para establecer un consenso sobre la complejidad y esfuerzo de resolver algo. Este valor está influenciado por la complejidad misma de resolución del problema, el nivel de incertidumbre y riesgos asociados. Nota al final, este valor no está asociado a tiempo.
Hace 1 mes que llevo trabajando en el sistema agil pero hay algo que aun no entiendo del todo, si un sprint se mide por tiempo (dos semanas aprox) como puedo relacionar eso con los story points que no se miden en tiempo si no a esfuerzo?, no se si me logro hacer entender.
La idea general de Scrum, especialmente; es conocer qué cantidad de complejidad o de trabajo podemos lograr en una caja de tiempo. A esa caja de tiempo se denomina Sprint, y como bien dices, es tiempo (horas, días, semanas). Los Story points es una forma de representar la cantidad de complejidad, incertidumbre, riesgo y esfuerzo que representa hacer un trabajo (recuerda que esfuerzo y tiempo son medidas diferentes). No se relaciona con tiempo, no hay una equivalencia entre puntos y horas, porque el propósito del story point es simplemente lograr un consenso de equipo sobre la complejidad de crear algo (y dejarlo en Done). En la práctica, los puntos sirven para conocer la cantidad de trabajo que un equipo puede abordar en un sprint.
Excelente me ayudo a entender :D! Buen articulo
Muchas gracias Pierre!
Hola Johnny,
Muchas gracias por el artículo, sin embargo tengo una pregunta, si las estimaciones de esfuerzo las hacemos en Story Points, que no tienen una equivalencia en tiempo, ¿como podemos dar una estimación en tiempo de la duración del proyecto?
Hola Alexandra! Antes que nada, muchas gracias por leer y por tu comentario. Si me permites te brindo mi respuesta: en Agile, el paradigma de predicción y estimación cambia de estimar la duración hacia valorar el alcance que puede ser logrado en una caja de tiempo fija. Es decir, el triángulo de acero de un proyecto se invierte; de esta forma. La contra-pregunta es: En este tiempo de 6 meses (por ejemplo), con el equipo que tengo, ¿qué alcance consideramos que podemos lograr? Y por consiguiente: ¿qué de esto es lo más valioso para ti? Entonces surge la necesidad de priorización. Te comparto esta presentación con más detalle sobre planificar proyectos con ágil, estimación y respuestas a tiempos y alcance: https://www.slideshare.net/JohnnyDark/entendiendo-el-triangulo-de-acero-en-agile