Para realizar las estimaciones se junta el equipo de desarrollo con el propietario de producto o los interesados que sean necesarios. Cada uno de los miembros del equipo de desarrollo cuenta con una bajara con cartas que tienen los siguientes valores:
Secuencia de Fibonacci: 0,5, 1, 2, 3, 5, 8, 13, 21,…
También hay equipos que utilizan otros valores, pero esta secuencia es quizás las
más común. Cada carta representa el valor de la estimación que considera más adecuada cada miembro del equipo. La unidad de medida será la que convenga el equipo si bien es habitual utilizar “puntos de historia” que representan el esfuerzo que ha llevado la realización de un requisito conocido por todos los miembros. Esta
analogía permite al equipo tener conciencia entre la diferencia existente entre el tiempo real y el ideal, es decir, entre el tiempo que realimente lleva un desarrollo frente al que llevaría en condiciones totalmente ideales. Por ejemplo, un partido de
baloncesto tiene una duración ideal de 40 minutos, pero en tiempo real puede durar 60 minutos o más. Si la carta elegida es la de valor cero significará que el requisito ya está desarrollado y que no será necesario ningún esfuerzo adicional.
Interrogación (?): esta tarjeta se muestra cuando una persona del equipo no puede dar una estimación por no haber entendido suficientemente el requisito. De este modo solicita más información para poder realizar una estimación.
Infinito (∞): esta carta se muestra cuando una persona del equipo considera que el requisito es demasiado grande para ser estimado y sugiere que se divida en requisitos más pequeños.
Descanso: esta carta que se suele representar con una taza de café significa que se está demasiado cansado para seguir realizando estimaciones y sugiere que se haga un descanso o se finalice la sesión.
La mecánica de la reunión es muy sencilla. El propietario de producto o el interesado presenta un requisito e inmediatamente después cada uno de los miembros del equipo levanta una carta con su estimación.
Si los valores son iguales o similares ya se tiene una estimación. En caso contrario se proporciona más información a través de las preguntas que el equipo de desarrollo formule para, posteriormente volver a realizar una estimación. Si después de dos o tres intentos no se consigue un consenso sobre la estimación, se puede avanzar con otros requisitos para, al final de la reunión, confiando en que otros
requisitos hayan proporcionado un visión más amplia de éste, se pueda realiza una estimación con consenso. Si nuevamente no se llega a un consenso el Scrum Master puede decidir cual es la estimación. Se debe evitar hacer medias aritméticas pues el objetivo de esta técnica es principalmente facilitar un mayor conocimiento de los requisitos, lo que es mucho más importante que una valoración del esfuerzo.
Entre los beneficios de la planificación póquer están:
Evita ver las estimaciones como valores exactas del esfuerzo a través de valores cada vez más alejados unos de otros.
Estimula la división de los requisitos y tareas en partes más
pequeñas.
Reduce el esfuerzo dedicado a realizar estimaciones.
Facilitar un mayor entendimiento de los requisitos por parte de los miembros del equipo de desarrollo.
Desarrollo el trabajo en equipo entre los interesados y el equipo de
desarrollos
Buscando por “planning poker” en cualquier buscador es fácil encontrar
barajas o plantillas y aplicaciones gratuitas o de pago para dispositivos
móviles. Un servicio web muy útil para familiarizarse con está técnica
es http://www.planningpoker.com/ siendo de uso gratuito.
snowghoul
annaxmalina
vaporwave
romaincrisis
jbbartram-illu
titsay
blakekathryn
2087