La actividad Planning Poker

La técnica de Planning Poker, es una práctica ágil ideada por James Grenning, cuyo propósito es estimar el esfuerzo y duración de las tareas en cada Sprint.

En un primer momento, el modelo inicial consta de 8 cartas donde cada participante consta de un juego de cartas. De forma individual cada participante estima el esfuerzo que puede demorar una tarea, luego todos muestran su carta boca arriba y se suma el esfuerzo estimado.

Cuando el esfuerzo es considerado demasiado extenso, se levanta la carta “∞”. Estas tareas que exceden el tamaño máximo deben descomponerse en subtareas de menor tamaño.

Cada equipo puede utilizar un juego de cartas con las numeraciones adecuadas a la unidad de esfuerzo con la que trabajan, y el tamaño máximo de tarea o historia que se va a estimar.

Variante: Sucesión De Fibonacci

Esta variante basada en la sucesión de Fibonacci, comienza con los números 0 y 1, y a partir de estos, cada término es la suma de los dos anteriores.

Esta técnica es utilizada, basada en el hecho de que al aumentar el tamaño de las tareas, aumenta también la incertidumbre y el margen de error. Importante conocer que la estimación no se realiza levantando varias cartas para componer la cifra exacta, sino poniendo boca arriba la carta con la cifra más aproximada a la estimación.

Los números se representan como la siguiente figura:

Figura. Cartas del planning poker (Fibonacci). Tomado de Scrum Manager

Es frecuente que se emplee una carta con un símbolo de duda o interrogación para indicar que por alguna razón no se puede precisar una estimación. Se puede incluir también una carta con alguna imagen que indique que se necesita un descanso

Modo de actuación:

1. Para cada tarea (historia de usuario o funcionalidad) el Product Owner expone la descripción empleando un tiempo máximo.
2. Se establece otro tiempo para que el Product Owner clare las posibles dudas del equipo.
3. Cada participarte selecciona la carta, o cartas que representan su estimación, y las separa del resto, boca abajo.
4. Cuando todos han hecho su selección, se muestran boca arriba.
5. Si la estimación resulta “infinito”, por sobrepasar el límite máximo establecido, la tarea debe dividirse en subtareas de menor tamaño.
6. Si las estimaciones resultan muy dispares, se puede optar por las siguientes interrogantes:

•  ¿Por qué es necesario tanto tiempo? y ¿por qué es necesario tan poco tiempo? Tras escuchar las razones, se repite la estimación.
• Dejar a un lado la estimación de esa tarea y retomar al final o en otro momento aquellas que hayan quedado pendientes.
• Se puede solicitar al Product Owner un desglose la funcionalidad y valorar cada una de las funcionalidades resultantes.

Este protocolo, evita en la reunión atascos de análisis circulares entre diversas opciones de implementación, hace participar a todos los asistentes, reduce el cuarto de hora o la media hora de tiempo de estimación de una funcionalidad, consigue alcanzar consensos sin discusiones, resulta divertido y dinamiza la reunión de planificación.

Lubaris Info 4 Media S.L. (2014). Gestión de Proyectos Scrum Manager. Obtenido de http://www.scrummanager.net