Este es un juego creado por James Grening en 2002, con el cual utilizando cartas de Planning Poker con los números correspondiente a la serie de Fibonacci (0, 1, 2, 3, 5, 8, 13, 20, 40 y 100…), con el cual podemos llegar a realizar estimaciones en equipo a través del consenso.
HISTORIAS DE USUARIO Y PUNTOS DE HISTORIA
Como hemos mencionado con anterioridad el planteamiento de historia de usuarios o user stories, es la técnica más utilizada para describir los requisitos en nuestro Product Backlog.
En muchos casos, la estimación de estas historias se suele realizar utilizando una medida relativa conocido como Story Points.
Los story points son una medida de la complejidad o el esfuerzo necesarios para completar una historia de usuario (actividad o tarea) en un proyecto de software. Se utilizan en metodologías ágiles, como Scrum, para estimar el tiempo y el esfuerzo necesarios para completar tareas y para priorizar el trabajo.
Los story points se asignan a cada historia de usuario utilizando una técnica de estimación, como el Planning Poker. Los puntos se asignan en una escala, que aunque no es obligatorio suele ser la escala de Fibonacci, y se utilizan para comparar la complejidad de las distintas historias de usuario. Por ejemplo, una historia de usuario con una puntuación de 13 podría considerarse más compleja que una historia de usuario con una puntuación de 5.
Los puntos de historia se utilizan para estimar el tiempo y el esfuerzo necesarios para completar tareas, pero no se correlacionan directamente con el tiempo en horas o días. En lugar de eso, se basan en la experiencia y la percepción del equipo de desarrollo sobre la complejidad de las tareas y se utilizan para comparar la carga de trabajo entre distintas historias de usuario.
LA ESTIMACIÓN RELATIVA
Las técnicas de estimación relativa como su nombre lo indica, comparan el tamaño relativo de dos o más elementos, en lugar de estimar el esfuerzo total requerido para realizar una determinada actividad.
Por ejemplo, cuando pedimos un vaso de refresco en una cafetería, podemos optar por un vaso pequeño, mediano o grande. Del mismo modo, que cuando al comprar una camiseta, podemos elegir su talla: pequeña, mediana, grande o extragrande. En ambos casos estamos comparando el tamaño, en lugar de medirlo.
De esta misma forma, podemos establecer el tamaño estimado de una historia de usuario, utilizando la técnica de puntos por historia, donde compararemos el tamaño de las historias, considerando la medida relativa de esfuerzo, complejidad y riesgo involucrados en el desarrollo de esa historia.
Vale la pena aclarar, que, si bien el uso de las historias de usuario presenta algunas ventajas, como aportar mayor claridad a los requisitos a través de los criterios de aceptación y una visión del valor percibido desde el punto de vista del usuario. Su uso, no es obligatorio, los requisitos pueden redactarse en cualquier otro tipo de formato, siempre y cuando sean claro y entendible para los desarrolladores.
MEDIDAS DE ESTIMACIÓN
Al estimar por puntos de historia, las historias de usuario reciben una cierta cantidad de puntos basada en su tamaño relativo.
Por lo general, los equipos suelen utilizar la escala de Fibonacci modificada (pseudo Fibonacci), constituida sólo por los números 1, 2, 3, 5, 8, 13, 20,40,80 y 100, estos valores representan el número de puntos de la historia, u otras unidades en las que el equipo estima.
En mi caso en particular cuando algún miembro del equipo otorga una puntuación de a partir de 13 esa historia debe revisarse ya que seguramente estamos frente a una épica. Algunos de ustedes pensaran que 13 no es un número muy alto, pero recuerden que hablamos relativamente, por lo que considero que entre 8 y 13 el margen de error es bastante grande, como se puede observar en la imagen.
Algunos equipos también optan por otro tipo de medidas relativas, como por ejemplo las tallas de camiseta, pero esto implica que el resultado no sea un valor numérico, por lo que después se debe realizar dicha conversión.
PLANNING POKER
Planning Poker es una técnica ludificada, basada en el consenso, que se utiliza para realizar estimaciones relativas. Este juego fue creado por James Grenning, en 2002, sin embargo, se popularizó en 2006 a través del libro “Estimación y planificación ágiles” publicado por Mike Cohn.
Actualmente Planning Poker es quizás la técnica más común para estimar los elementos del Product Backlog al adoptar el framework de Scrum.
El funcionamiento del de la sesión de Planning Poker es bastante sencillo, en su teoría, pero a la hora de aplicarlo, sobre todo por primera vez en un equipo, puede ser algo caótico y desgastante o por el contrario silencioso e improductivo.
Cada desarrollador tendrá a su disposición las tarjetas numerados en una secuencia generalmente similar a la descrita anteriormente. También se incluyen en el mazo cartas con el signo de pregunta (o infinito) para aquellas historias que el desarrollador no sabe valorar y la de café, para esas pausas necesarias ante una tarea tan exigente.
PLANNING POKER PASO A PASO
Al comenzar la sesión el Product Owner presenta uno a uno según orden de priorización del Product Backlog los requerimientos al equipo de desarrollo, después de esta explicación quien lo necesite hará las preguntas que crean necesarias al Product Owner, para tener un completo entendimiento de la historia de usuario que se va a estimar.
Cuando la historia ya está completamente clarificada, comienza la votación que definirá su tamaño. Cada miembro del equipo de desarrollo reflexiona individualmente sobre lo presentado por el propietario del producto y selecciona la carta de Planning Poker, con la cantidad de puntos que creen que son apropiados para ese elemento.
La estimación se obtiene comparando el artículo a estimar con el historial de referencia. Por ejemplo, si el desarrollador entiende que la historia que se estima es dos veces más compleja que la historia de referencia (estimada en 2 puntos), luego pueden optar por asignar 5 puntos a la historia que se está estimando.
Luego, se inicia una ronda de descubrimiento de cartas de forma simultánea para evitar sesgar la decisión entre los participantes. Es importante recalcar que la carta no se debe mencionar antes, para no influir en la estimación de los demás desarrolladores.
Si existe una discrepancia entre dos estimaciones se produce la conversación en busca de construir una imagen común del trabajo, luego de que cada parte haya expuesto sus argumentos, se lleva adelante otra ronda.
Suele suceder que, a partir de la segunda ronda gracias a las conversaciones del equipo, los números se aproximan, cuando esto sucede, definimos el valor estimado del artículo del Backlog de Producto.
La decisión del valor escogido dependerá de muchos factores, como la madurez del equipo, la pericia en proyecto de características similares, entre otros, los equipos generalmente realizan acuerdos previos para determinar con qué criterio escogerán del valor, dependiendo de su situación.
Lo que no recomiendo es realizar estimaciones por promedio de puntos ya que no estaríamos realizando Planning Poker.
Finalmente, después de haber calculado el valor de todas las historias procederemos a sumar los puntos, los que nos dará una estimación relativa del tamaño de nuestro Product Backlog.
Posteriormente conociendo este dato, habiendo establecido la Definition of Done de al menos un Spring, calculando el tiempo de gestión de Scrum y los spikes, podremos determinar un poco más acertadamente el esfuerzo que requerirá nuestro proyecto.