Si deseas conocer otra manera de estimar historias de usuario dentro de un entorno incierto, con técnicas que permitirán mejorar la productividad de los equipos y además romper la premisa que establecía que el éxito de un proyecto se medía si terminaba dentro del tiempo, alcance y costo establecidos, este artículo es para ti.
Planear en la gestión de proyectos y productos es una de las actividades más recurrentes que existen, siempre se procura predecir y estimar lo que va a suceder, tratando de tener la mayor precisión y poder seguir un plan.
Esto suena perfecto, sin embargo, dista mucho en una «nueva realidad», de entornos VUCA (Volatilidad -volatility-, Incertidumbre -uncertainty-, Complejidad -complexity- y Ambigüedad -ambiguity-) y BANI (Quebradizo –Brittle-, Ansioso, No lineal e Incomprensible) –BANI- del futurista y antropólogo Jamais Cascio en su artículo Facing the Age of Chaos, en ellos, la planificación se acerca más a una predicción que toma elementos conocidos, usando la estimación como un medio para inferir el tamaño de las tareas y el esfuerzo de los equipos que están desarrollando productos en entornos empíricos, implantados dentro del modelo Cynefin (Snowden, 2020), especialmente en los cuadrantes de lo complejo y lo caótico, alineado con la usabilidad de los marcos de trabajo ágiles para tal fin, donde la estimación de historias de usuario cobra sentido.
Basado en book-of-ours.com
El camino hacia la estimación ágil
Lo primero que hay que entender es que estimar al inicio de un proyecto o un producto es poco preciso, tal como mostró en 1981, Barry Boehm cuando dibujó la primera versión de lo que Steve McConnell (1998) más tarde llamado el «cono de incertidumbre» (Cohn, 2005, p.4) en proyectos tradicionales.
Cono de la incertidumbre. Tomado de Agile Estimating and Planning (Mike Cohn)
El cono de la incertidumbre explica gráficamente que, a medida que un proyecto avanza, la precisión de nuestras estimaciones aumenta. Al inicio siempre existirá mucho desconocimiento y no se conocerá mucho sobre el producto, por lo que se dará una estimación que está lejos de la realidad, en un rango de entre un 60% y un 160%, así se haga un gran esfuerzo en el proceso de estimación de historias de usuario. En el caso de proyectos ágiles el cono es muy similar, mostrando que a medida que pasan los Sprints, las estimaciones serán más precisas, disminuyendo la variabilidad. Es así, que la estimación y la planificación en enfoques iterativos e incrementales es una búsqueda de valor para que el equipo se empodere en la búsqueda de lo que se debe construir con el paso de los días, ir ganando madurez y confianza en la autoorganización, teniendo conversaciones útiles para saber cómo construir y qué priorizar en el backlog.
Conoce más sobre ¿Por qué hacer sesiones de refinamiento del product backlog?
Estimación relativa y los Puntos de Historia
Dentro de los marcos de trabajo ágiles existen iteraciones similares llamados Sprints, las cuales tienen un backlog que tienen tareas llamadas historias de usuario y en otros casos Product Backlog Item, que a su vez deben ser estimadas para estipular el esfuerzo que cada uno necesitará. Hay investigaciones que demuestran que las personas somos mejores estimando el tamaño de algo comparándolo con un referente, a lo que se le llama estimación relativa. Un ejemplo conocido de esto es cuando se hace la pregunta de cuánto mide un edificio, la respuesta en metros es difícil de acertar, además es un valor absoluto; es mucho más fácil decir que otro edificio que está lado es más pequeño, tal como se ve en la gráfica a continuación:
Edificios más altos del mundo. Tomado de Cultura Genial (2020)
En el ejemplo citado, sólo se necesitaba saber la diferencia relativa entre los dos edificios, por lo que se puede tener un ejemplo concreto con el que comparar, teniendo un “punto de pivote”, que es el referente para calcular la altura de otros edificios. Esta facilidad que da el tener una referencia concreta con la que comparar es una de las razones por la que la estimación relativa es muy usada en agilidad, dando una familiaridad al equipo con ese punto de pivote, siendo más rápida y fácil el ejercicio de estimar.
Pasando a la gestión de proyectos o productos, muchos equipos que acostumbran el uso de herramientas y técnicas tradicionales estiman la dificultad de una tarea por tiempo (horas, semanas o meses). Luego en agile se introduce un concepto llamado puntos de historia (Story Points), que es una técnica para medir el esfuerzo en una escala relativa de una historia de usuario, permitiendo una descripción más precisa del esfuerzo de la tarea a realizar. Una historia de usuario con ocho puntos de historia es cuatro veces más grande y arriesgada que una historia estimada en dos puntos de la historia.
En lo relacionado con Puntos de Historia, si se estimara con una secuencia lineal (Ej. 1 a 100) sería muy arriesgado y complicado diferenciar la complejidad entre una tarea con un puntaje de 60 y otra de 62. Para solucionar eso, se propuso usar una sucesión de números con distancias que sean relativas, tal como pasa con la serie Fibonacci, donde es más fácil separar las tareas de dificultad 13 de las de 21, ya que la de esfuerzo de 21 puntos es más difícil, pero no es el doble que la de 13 puntos. Esta serie hace que la importancia esté en las distancias que existen entre los números y no en los números en sí.
Historia corta de la serie de Fibonacci
Imagínate que por alguna razón del destino tuvieras que estimar cuántos conejos nacen de una pareja de conejos y la naturaleza de los conejos es tal, que cada pareja produce otra pareja (macho y hembra) al cabo de un mes y las conejas pueden parir a los dos meses de haber nacido, además nunca mueren. Puesto que la primera pareja da descendencia el segundo mes, ya hay 2 parejas; de ellas, la primera pareja, produce también al mes siguiente, de modo que en el tercer mes resultan 3 parejas; de ellas, al mes siguiente 2 parejas darán descendencia de modo que en el cuarto mes nacerán 2 parejas más y el número de parejas llegará a 5. Y así se puede hacer en el mismo orden hasta un número infinito de meses (Leonardo de Pisa, 1202, como se citó en Vorobiov, 1974).
Tomado de juntadeanadlucia.es
El relato anterior fue uno de los numerosos problemas que se planteó Leonardo de Pisa, más conocido como Fibonacci (abreviatura de filius Bonacci, es decir, hijo de Bonacci) en su libro Liber Abaci (Libro del Ábaco), llevó a la introducción de una de las sucesiones numéricas más conocidas, la serie de Fibonacci.
En la historia de los conejos, el número de pares al inicio de cada mes es 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144…; esto es una serie en la que cada número es la suma de las dos anteriores: 0, 1, 1 (1+0), 2 (1+1), 3 (1+2), 5 (2+3), 8 (3+5), 13 (5+8), 21 (8+13) y así consecutivamente. La sucesión de Fibonacci fue alcanzando una notoria fama justificada por los descubrimientos de otros matemáticos y físicos que la asociaron prácticamente con todo lo que sucede en el universo, desde la disposición de las hojas, flores, semillas y ramas en la naturaleza -conocida como filotaxis-, así como diversas áreas como la predicación de los mercados financieros, la creación de las galaxias y los huracanes. En agilidad se usa para estimar el esfuerzo requerido para completar una tarea, utilizando técnicas como el Planning Poker.
Técnicas de Estimación ágil: Planning Poker y T-Shirt Sizes
Planning Poker
Usando la sucesión de Fibonacci para estimaciones en el framework eXtreme Programming (XP), James Greening (2002) creó un juego de cartas al que llamó Planning Poker con el fin de facilitar la conducción de los eventos (Sprint Planning y Refinamiento) y así, reducir el tiempo que estaban tardando las estimaciones e involucrar a todos los miembros del equipo en esta actividad.
Planning Poker. Tomado de easyagile.com
El juego inicia en el Sprint Planning o en el refinamiento, cuando el Product Owner comenta una historia de usuario del Backlog del Sprint o del producto, la explica y luego todos los developers aclaran sus dudas y se disponen a arrojar una tarjeta según la cantidad de esfuerzo o puntos de historia que consideran tiene ese elemento en particular. Todos revelan la carta al mismo tiempo.
Si hay consenso, no es necesario debatir. Si los miembros del equipo tienen opiniones diferentes deben discutir por qué eligieron ese número específico. Posteriormente vuelven a votar hasta que se llegue a un consenso.
Lo más importante es que todos miembros del equipo participen del juego. Así mismo, pueden analizar las historias de usuario antes de iniciar el trabajo, pudiendo llegar a puntos de encuentro que facilitarán sus funciones a futuro. Por último, el equipo tarda muy poco en estimar las historias de usuario más familiares o sencillas.
T-Shirt Sizes (Talla de Camiseta)
Existen más técnicas para realizar estimaciones y una de ellas es T-Shirt Sizes o Talla de Camiseta, que es una variante del Planning Poker. Lo primero que se hace es definir la tallas, que normalmente son XS, S, M, L y XL. Luego se le asigna un valor cada camiseta, que se sugiere esté relacionada con la serie Fibonacci (saltos relativos), ya que la estimación en tallas de ropa sugiere erradamente que los escalones o saltos son iguales. Es una técnica fácil de usar, pero se sugiere solo cuando se necesite hacer una estimación rápida y de alto nivel.
En conclusión, la estimación ágil permite medir la productividad y velocidad de los equipos; facilita el entendimiento entre los miembros del equipo y de sus formas de trabajo (Ways of Working), además genera una cultura de respeto, participación, empoderamiento y autoorganización.
Si quieres más información respecto a los marcos de trabajo ágiles y llevar tu organización al siguiente nivel, te invitamos a seguirnos en Facebook, Instagram, LinkedIn y YouTube y a tomar nuestros cursos de capacitación. ¡Conócelos!
Bibliografía