Planning poker

Planning Poker es una técnica para calcular una estimación basada en el consenso, en su mayoría utilizada para estimar el esfuerzo o el tamaño relativo de las tareas de desarrollo de software. Es una variación del método Wideband Delphi. Es utilizado comúnmente en el desarrollo ágil de software, en particular en la metodología Extreme Programming.

El método fue descrito por primera vez por James Grenning en 2002 y más tarde se volvería más popular y comercial por Mike Cohn con el libro Agile Estimating and Planning.

Equipamiento

El planning poker, está basado en una lista de características que deben ser estimadas y una baraja de cartas por cada participante. La lista de características, por lo general una lista de historias de usuario, describe el software que se va a desarrollar.

Las cartas en el mazo están numeradas. Un mazo típico contiene tarjetas con sucesivos términos de la sucesión de Fibonacci incluyendo un cero: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89; a razón de reflejar la incertidumbre inherente en la estimación en el proyecto. Otros mazos utilizan progresiones similares.

Un mazo que se encuentra en el mercado utiliza la siguiente secuencia: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 y además, dos tarjetas: una con signo de interrogación (?) y otra con signo de infinito (∞). Ambas pueden ser usadas para declarar completa incertidumbre o desconocimiento de la característica. También puede existir una carta con el dibujo de una taza de café que puede usarse para indicar que un participante está demasiado cansado para continuar y necesita un descanso.​

Procedimiento

En la reunión de la estimación, a cada participante o estimador, se le da un conjunto completo de tarjetas.

La reunión prosigue de la siguiente manera:

• Un moderador, que no jugará, preside la reunión apoyado y asesorado por el Gestor del Proyecto.
• El desarrollador con más conocimiento de una determinada característica proporciona una breve introducción sobre la misma. El equipo tiene la oportunidad de hacer preguntas y discutir para aclarar los supuestos y riesgos. Un resumen de la discusión es registrado por el Gestor del Proyecto.
• Cada persona coloca una tarjeta boca abajo que representa su estimación. Las unidades utilizadas pueden ser variadas y definidas previamente. Pueden ser días de duración, días ideales o puntos de historia. Durante el debate, los números no deben ser mencionados en absoluto.
• Todo el mundo muestra sus tarjetas de forma simultánea.
• A las personas con estimaciones altas y bajas se les da un tiempo para ofrecer su justificación para la estimación y la discusión continúa.
• Se repite el proceso de cálculo hasta que se alcance un consenso. El programador que probablemente tenga el "entregable" tiene una gran parte del voto de consenso, aunque el moderador puede negociar el consenso.
• Se puede utilizar un reloj de arena para asegurar que el debate sea estructurado. El moderador o el Gestor del Proyecto, podrá en cualquier punto, terminar el reloj y cuando se acabe toda la discusión, debe cesar para que se pueda jugar otra ronda.

Las cartas están numeradas de esta manera para explicar el que, cuanto mayor sea una estimación, mayor será la incertidumbre. Así, si un jugador quiere jugar un 6 se ve obligado a reconsiderar y aceptar que parte de la incertidumbre percibida no existe y jugar un 5, o aceptar una estimación más conservadora de la incertidumbre y jugar un 8.

Beneficios del planning poker

El planning poker es una herramienta para la estimación de los proyectos de desarrollo de software. Es una técnica que minimiza el anclaje, pidiendo a cada miembro del equipo jugar su tarjeta de estimación de manera tal que no puede ser visto por los demás jugadores. Después de que cada jugador ha seleccionado una tarjeta, todas las tarjetas son expuestas a la vez.

Un estudio realizado por K. Molokken - Ostvold y NC Haugen encontró que las estimaciones obtenidas mediante el proceso de Planificación de poker son menos optimistas y más precisas que las estimaciones obtenidas a través de la combinación mecánica de las estimaciones individuales en las mismas tareas.^{[cita requerida]}

Evitar el anclaje

El anclaje se produce cuando el equipo discute sus estimaciones antes de realizarlas. Un equipo contiene normalmente estimadores conservadores e impulsivos. Además, algunas personas tienen fechas ya planificadas. Es probable que los desarrolladores quieran todo el tiempo que puedan conseguir para hacer el trabajo, y el Product Owner desee que se realice tan rápido como sea posible.

La estimación se ancla cuando el Product Owner dice algo como: "Creo que es un trabajo fácil, no veo que lleve más que un par de semanas", o cuando el promotor dice algo como: "Creo que tenemos que tener mucho cuidado, solucionar los problemas que hemos tenido podría llevar meses". Cuando alguien inicia la estimación diciendo algo como "creo que son 50 días" inmediatamente tiene un impacto en el pensamiento de los otros miembros del equipo. Sus estimaciones se han anclado. Es decir, todos harán una referencia, al menos subconsciente, al número 50 en sus propias estimaciones. Los que estaban pensando en 100 días es probable que reduzcan esa cifra, y aquellos que pensaban en 10 se pueden replantear incrementar tal cantidad. Esto se convierte en un problema aún mayor si el que menciona la cifra 50 es un miembro influyente del equipo. Debido a que el resto de los componentes del equipo se han anclado pueden, conscientemente o no, no expresar su estimación original. De hecho, es posible que incluso lleguen a creer que ellos estaban pensando en la misma cifra. Esto puede ser peligroso ya que fechas planificadas previamente u opiniones individuales que no se centran en conseguir un trabajo bien hecho pueden influir en las estimaciones.

Con el Planning Poker la opinión de los miembros del equipo potencialmente influyentes es aislada inicialmente del resto del grupo. A continuación, ese miembro podrá argumentar su opinión si es contraria a la del resto. De esta manera el grupo será más propenso a tener fe en sus estimaciones originales. Si la persona influyente puede argumentar su estimación correctamente todos verán que tiene sentido, y la aceptarán igualmente, pero por lo menos el resto del equipo no se ha anclado, sino que han atendido a las razones dadas.

Enlaces externos

• Web oficial

• Datos: Q2980731