El planning poker es una de las mejores herramientas para hacer estimación del esfuerzo para cada una de las necesidades descritas en el Product Backlog. Si tu y tus compañeros de equipo sois capaces de determinar el esfuerzo, tendréis control sobre la “cantidad” de trabajo de calidad que sois capaces de entregar en cada ciclo (sprint). Si sabéis esto, teneis la mejor herramienta para clasificar y priorizar las necesidades descritas por el usuario, y saber con mucha exactitud tempos y duración del proyecto.

El equipo (y solo el equipo) ha de aprender a consensuar el esfuerzo que comporta hacer realidad cada ítem del product backlog. La única forma de conseguir esto es con la práctica y dialogando de forma abierta y sincera con los compañeros. El Planning Poker es una herramienta que puede ayudar a conseguir este nivel de experiencia necesario.

Las normas

Antes de empezar conviene puntualizar que el planning poker es una actividad enfocada a la estimación de historias de usuario. Las historias de usuario no se tasan en tiempo ni en coste económico. Deben tasarse en un valor relativo que da una orientación sobre el esfuerzo para el equipo. En caso de que el equipo decida, por su organización, dividir las historias de usuario en tareas técnicas, estas si pueden estimarse en horas

Hay diferentes modalidades para hacer estimación con planning poker, pero todas ellas están sujetas a las mismas reglas esenciales, y que conviene recordar:

1. Previsión: El planning poker no se lleva a cabo en el momento de hacer la planificación del sprint. En el Sprint Planning los ítems susceptibles de entrar en el Sprint ya han de estar valorados.
2. Definición: Los ítems del product backlog a valorar, ya han de estar suficientemente definidos y sin presentar grandes dudas en el equipo. El planning poker no es el momento de negociar la funcionalidad o de resolver grandes dudas con el usuario.
3. Responsabilidad: Solo los técnicos (developers) hacen estimación. El Scrum Master puede estar presente en la sesión e incluso puede participar si al resto del equipo le parece bien. Pero solo el equipo tiene la responsabilidad. Ni el Product Owner ni los usuarios pueden participar.
4. Consenso: Para cada ítem a estimar, una persona del equipo (la que tenga más conocimiento sobre el ítem en cuestión) da la explicación al resto del equipo. Antes de que nadie haga público su opinión sobre la valoración, deben resolverse las dudas que pueda haber. Es el momento de hablar sobre la funcionalidad y las dificultades técnicas que conlleva hacerla realidad. Esta es la parte más importante de la sesión.
5. Imparcialidad: Mientras se está explicando y negociando la funcionalidad, nadie puede opinar sobre su pretensión de valoración en story Points. Se trata de no influir al resto del equipo. El Scrum Master debe estar atento a que el equipo desarrolle la actitud de imparcialidad necesaria.
6. Estimación: Cuándo todo está claro ya puede procederse a hacer la estimación. Todos los participantes lo harán al mismo tiempo, presentando una carta con su valoración.
7. Alineamiento: En el caso de que las valoraciones sean muy dispares, es necesario que la persona que ha valorado más bajo, i la que ha valorado más alto, expliquen sus motivos.

El procedimiento de valoración vuelve a repetirse hasta que se obtenga un consenso sobre el esfuerzo de llevar a cabo la funcionalidad sometida a votación, de forma que todo el equipo esté alineado sobre el esfuerzo.

Es pueden utilizar cartas, aplicaciones o plantillas con los valores permitidos.

Algunas plantillas de ejemplo

Ejemplo 1		Ejemplo 2

La numeración de las cartas

Tradicionalmente, las cartas de planning poker acostumbran a seguir una numeración que es próxima a la sucesión de Fibonacci, con los valores siguientes:

• 0 - La tarea es trivial y no tiene valoración. Deberíamos estudiar si realmente el ítem tiene valor para los usuarios y la organización
• 0.5 - Este valor no es habitual en todos los proyectos. En ocasiones es preciso indicar que, aunque sabemos que una tarea es trivial; por sus características o por cuestiones organizativas, sería deseable incluirla como historia de usuario válida e independiente
• 1, 2 i 3 - Historias sencillas. Sin dificultades técnicas aparentes
• 5 i 8 - Historias sencillas con alguna dificultad técnica
• 13 i 20 - Historias con complejidad técnica
• 40 - Historias con mucha dificultad técnica
• 100 - Historias con mucha dificultad técnica y con un alto riesgo de no ser entendida correctamente debido a su tamaño
• ∞ - Quimera. La historia no se entiende y/o es demasiado grande

Un ejemplo de cartas con la sucesión de Fibonacci

Otras formas de hacer estimación

Otra forma de hacer estimación, y que tiene mucho éxito entre los equipos de proyecto, es hacer estimación con otros gradientes no numéricos. Por ejemplo, con tallas de ropa:

• XS - Historia trivial
• S - Historia sencilla y sin dificultades técnicas
• M - Historia con alguna dificultad técnica
• L - Historia con dificultades técnicas relevantes
• XL, XXL, etc - Historia con mucha dificultad técnica o tamaño

Descárga el documenot con las cartas para imprimir

En el enlace siguiente puedes encontrar los archivos de las cartas con sucesión de Fibonacci y tallas para que las puedas imprimir. El archivo contiene los PNG de cada una de las cartas, y dos PDF con las cartas en diferentes tamaños para impresión.

He realizado el diseño de cartas que me gustaría tener para mis equipos. Y lo son porque soy consciente que a menudo con la numeración de la secuencia de Fibonacci no es suficiente. En equipos nuevos es habitual no tener una idea clara de que significa una tarea valorada en “20”. Las valoraciones en las primeras iteraciones acostumbran a ser demasiado altas. Y es una tendencia que conviene controlar y abordar ya desde la primera iteración.

Estas cartas llevan asociadas a cada valoración una imagen, que pretende dar una idea sobre la complejidad. Y pretenden explicar al equipo que, historias valoradas en 5, 8 o 13 son historias complejas. Y que historias valoradas en 20, 40 o 100 probablemente son historias de elevado riesgo para el equipo. Cuanto más grande es una historia, más riesgo hay de acabar haciendo un gran trabajo que no se adapta realmente a las necesidades del usuario. Es necesario que el equipo sea consciente de este riesgo para que pueda decidir si realmente acepta la construcción de una historia con este volumen, o prefiere dedicar tiempo en subdividirla en historias más asumibles.

La clave de todo esto es el MVP (Minimum Valuable Product). El equipo, incluyendo al Product Owner, tienen el reto de hacer entender a todas los interesados que los MVP han de significar incremento de valor asumible para todas las partes. Y que, por tanto, es necesario que todo el mundo se comprometa en el consenso del tamaño de los diferentes ítems del Product Backlog.

Descarga las cartas aquí

Alternativa al planning poker “de siempre”

El planning poker, como todas las actividades y buenas prácticas en agilidad, está vivo!! Hay alternativas y variantes al planning poker de toda la vida. En concreto hay una de muy interesante que explico a continuación. La podemos llamar Planning Poker por aspectos:

El equipo se reune para hacer estimación de una historia de usuario. Alguien la explica y es tiene un debate para alinear conocimiento alrededor de lo que se necesita. A la hora de hacer la estimación, cada miembro del equipo da un valor de 0 a 6 sobre los aspectos seguientes:

• Esfuerzo: De forma parecida al planning poker tradicional. ¿Qué esfuerzo crees que representa esta historia respecto a las otras? Un valor de 0 a 6
• Incertidumbre: ¿Qué posibilidad crees que hay de que aparezca algún elemento sorpresa que dificulte la consecución de esta historia? Un valor de 0 a 6
• Conocimiento: ¿Qué grado de dificultad crees que puede haber respecto a la necesidad de conocimientos técnicos o skills específicos para la consecución de esta historia? O, ¿Qué grado de trabajo en equipo crees que tiene esta historia (0=individual - 6=completamente en equipo)? Un valor de 0 a 6

La suma de los tres valores da un valor en story points para tu votación. Posteriormente la dinámica de consenso de una estimación consensuada es la misma que en el planning poker tradicional.