Estimación ágil con la técnica Planning Poker


Sin entrar en el tema de si se debe estimar o no en el desarrollo de software, es cierto que tener una estimación aunque sea a alto nivel nos será útil para tomar mejores decisiones a la hora de ordenar y priorizar el backlog. Por ejemplo si tenemos historia A y B, y la historia A aporta valor 100 con esfuerzo 100 y la historia B aporta valor 90 pero esfuerzo 10, seguramente sea más interesante hacer primero B antes que A.

La estimación ágil

En la estimación ágil perseguiremos los siguientes objetivos:

  • Tener diferentes puntos de vista. Está claro que 7 pares de ojos ven más que uno. En la estimación ágil se busca la democracia, que todo el mundo participe y diga la suya. Si hay discusión mejor, ya que de lo que se trata es de avanzar todo lo posible los problemas y tenerlos en cuenta desde el inicio. No debería haber personas con una voz y voto más fuertes que los demás.
  • Detectar posibles tareas ocultas y posibles obstáculos. La sesión de estimación es una de las primeras oportunidades de detectar riesgos que pueden comenzar a tratarse para que no se conviertan en impedimentos.
  • Tener una visión compartida de la que se viene encima. Es muy útil haber participado en las estimaciones para después hacer las planificaciones. Si conoces el tamaño de las historias y tareas es mucho más sencillo comprometerte con un plan de trabajo que si las estimaciones te vienen “impuestas”.
  • Tener estimaciones más realistas (no más precisas). La idea es que entre todos el numerito que salga sea lo más cercano a la realidad posible. Para ello necesitas eliminar la presión contractual, esto es, dejar margen para equivocarse y evitar así introducir buffers “inconscientes” por si acaso. Lo que buscamos es realismo, no precisión, es decir, quiero saber si una historia serán 3 o 5 días, si me dices que tardarás 26,5 horas dudaré de que hayas hecho un buen ejercicio de estimación.

Planning Poker

Una de las técnicas más efectivas y conocidas del mundillo ágil para estimar es el Planning Poker. Se trata de una dinámica ágil en la que se reúne el equipo con una baraja de Poker modificada y se hacen rondas de estimación con ayuda de estas cartas.

Material necesario

Para una sesión de estimación ágil será necesario que cada participante tenga una baraja de Planning Poker. Puedes descargar e imprimir tu propia baraja en este enlace. También puedes utilizar una app móvil si todos se llevan el teléfono, aunque le quita algo de glamour a la sesión.

En cada baraja hay una pseudo-secuencia de Fibonacci modificada. Yo recomiendo quedarme con solo las primeras cartas para evitar estimar tareas demasiado grandes. Así cada participante tendrá las siguientes cartas: 0,1/2, 1, 2, 3, 5, ? e infinito. El cero significa que la historia ya está hecha o no requiere ningún esfuerzo, el interrogante significa que nos falta información para estimar esa historia o tarea y el infinito es que es demasiado grande y hay que trocearla.

Trabajo previo

Además del material, antes de iniciar la sesión tendrás que tener claro en qué unidades vas a estimar. Es posible que para estimaciones alto nivel o de épicas o historias prefieras estimar en semanas ideales, mientras que para historias más pequeñas y tareas de bajo nivel prefieras estimar en días ideales. Un día ideal es el trabajo que consigue una persona en un día en el que no tiene interrupciones de ningún tipo y todo le sale a la primera. También es posible que decidas estimar en una medida relativa como puntos historia. En cualquier caso, lo importante es que todos sepan en qué medida se estima.

También será importante que todos sepan qué se incluye y qué no en la estimación, si se incluye alguna documentación, tests unitarios, tests de integración y cualquier otra cosa que forme parte del desarrollo. Yo personalmente recomiendo incluirlo todo en la estimación de las historias y separar solo la documentación (no los tests) al desglosarlo en tareas.

Planning Poker

Dinámica de la sesión

Una vez tenemos al material necesario la sesión contiene la siguiente dinámica:

  • Todo el equipo “se encierra” para estimar, y todos conocen lo que se va a estimar. Si hay gente que no está al tanto de lo que se va a estimar la sesión debe comenzar con una explicación y una sesión de preguntas para despejar cualquier duda sobre las historias que se van a estimar.
  • Una por una se leen y discuten las historias de usuario. Una vez todos tienen claro en qué consiste cada uno elige una carta en función del esfuerzo que prevé requerirá esa historia. No es posible seleccionar un valor no incluido en la baraja. Solo estiman los que después desarrollan (ni el Scrum Master ni el Product Owner estiman, solo resuelven dudas).
  • Si no hay consenso (lo normal con más de 2 participantes) se abre la discusión. No muy larga, por ejemplo se puede hacer que explique su elección el que tiene la puntuación más baja y más alta. Se repite la estimación nuevamente en busca de consenso. Si no se consigue a la segunda se vuelve a discutir. A la tercera si no hay consenso se escoge o bien la media o bien el máximo (mejor el máximo).

Al final de la sesión el resultado es una estimación consensuada y validada por todo el equipo para cada una de las historias o tareas seleccionadas. Si se trabaja con Sprints lo habitual es estimar alto nivel cuando los elementos entran en el backlog, y nuevamente cuando se realiza el sprint planning o backlog grooming si se hace por separado para estimar las tareas a bajo nivel.

Conclusión

Si bien es cierto que la estimación de tareas de desarrollo de software es una ciencia infusa, es posible mejorar notablemente la calidad de nuestras estimaciones con técnicas como Planning Poker. ¿Que por qué funciona Planning Poker? Porque unifica la opinión de varios expertos en lugar de depender de uno, ayuda a identificar más riesgos más pronto, define una visión única del trabajo por hacer, y obliga a defender las estimaciones dadas ante los compañeros.

Ni siquiera es necesario trabajar en un entorno ágil para aprovechar las ventajas de Planning Poker. Si estás trabajando en proyectos de software y necesitas cuantificar el trabajo pendiente, prueba a utilizar esta técnica y comprueba por ti mismo su eficacia.

También te puede interesar...

5 razones para estimar en puntos historia En agile no estimamos adivinando el tiempo que nos va a llevar una historia de usuario. Estimamos lo gorda que es en comparación al resto. Esta estima...
Estimación por afinidad, estimar a lo bestia La estimación por afinidad es una técnica de estimación que permite estimar un gran número de elementos en un tiempo ridículo. He estado en una sesión...
Reducir tiempos de desarrollo es una mala idea Existe un principio llamado Ley de Parkinson, muy aplicado en el trabajo del conocimiento en general y en el mundo del software en particular, que dic...

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

3 ideas sobre “Estimación ágil con la técnica Planning Poker

  • Mayon

    Aún utilizando esta técnica, es difícil lograr una estandarización del esfuerzo, pues queda a la subjetividad de cada equipo de trabajo, pero no solo ahí, se extiende al momento de la estimación y la configuración actual de ese equipo (expertiz, conocimiento del tema, número de integrantes, tiempo trabajando juntos, experiencia en scrum, etc.).

    Ejemplo: Si yo pregunto a varios equipos de trabajo, cuánto esfuerzo necesitan para mover una mesa 20 metros, y la mesa pesa 5 kg; todos tendrán una variación casi nula del esfuerzo. Si la mesa pesara 80 kg, la variación apenas incrementaría, y es que todos tienen el concepto de kilogramo.

    En cambio no es así con los puntos de esfuerzo: Si yo pregunto a los mismos equipos cuanto esfuerzo significa 20 puntos, la variación es bastante notoria. Conclusión: Para que este método sea efectivo, creo que los equipos que estiman ya deberían tener tiempo trabajando juntos y con experiencia en estimaciones, y aún así están susceptibles al cambio de la configuración del propio equipo en donde su estimación inicial ya no será la adecuada.

    • samuelcasanova Autor

      Hola Mayon.
      Como casi todas las técnicas, sirve para algunas cosas pero no para todas. No es el objetivo de esta técnica estandarizar estimaciones entre equipos. Si que sirve para lograr un entendimiento común de lo que se tiene que hacer, para saber más o menos el esfuerzo y complejidad que supone, para compartir conocimiento, para detectar riesgos técnicos de forma temprana, etc.
      Si lo que necesitas es poder comparar entre equipos, aún no está todo perdido. Puedes utilizar una escala de estimación compartida entre equipos y comparar las velocidades. Otra solución no tan intrusiva y más fiable es utilizar escalas de estimación propias de cada equipo, y tener un factor de conversión basado en un muestreo de N historias tipo estimadas por todos los equipos.
      Sobre escalas de estimación y puntos historia tienes más información en el siguiente artículo:
      https://samuelcasanova.com/2017/04/puntos-historia-en-agile/