En las metodologías ágiles es habitual desarrollar dos niveles de planificación:  una general, planificación de la versión, y otra más detallada, planificación de la iteración.

El objetivo de la planificación de la versión es calcular la dimensión del proyecto. Saber si estamos hablando de 10 o de 100, y tanto en Extreme Programming (Release planning) como en Scrum (estimación del product backlog) se realiza en una reunión en la que participa todo el equipo.

En ella el cliente, o el propietario de producto expone una a una las historias o funcionalidades que necesita y el equipo determina el tiempo que llevará su desarrollo.
Este proceso no es ajeno a los problemas típicos de dinámica de reuniones, y aunque tiene un guión concreto y conocido por todos los participantes, es habitual entrar en atascos de "parálisis por análisis", en los que los minutos van pasando sin que los participantes terminen de decidir entre las posibles soluciones para una determinada funcionalidad y fijen una estimación; y el moderador ve con impotencia cómo ha consumido ya 15 ó 20 minutos sin poder cerrar la primera funcionalidad, y la lista de las que aún están pendientes de valorar.

• Cada participante de la reunión tiene un juego con las 8 cartas de la figura.

• Para cada historia de usuario o funcionalidad de la pila del producto (product backlog) el cliente, moderador o propietario del producto (según sea) lee o expone la descripción empleando un tiempo máximo (No son aconsejables más de 2 minutos).

• Se da un tiempo para que el cliente o propietario del producto responda a las preguntas que puedan tener los estimadores.

• Terminadas las preguntas, cada participante selecciona, sin mostrarlas, una o dos cartas que suman el nº de días de trabajo necesarios. Si se estima que la funcionalidad necesita más de 10 días, se selecciona la carta "infinito". Cuando todos han hecho ya su elección, se ponen boca arriba en la mesa.
  

• Si no hay gran diferencia entre las estimaciones de cada participante, se toma como resultado la media.

• Si la estimación resulta "infinito", la funcionalidad debe dividirse para ajustarla a los criterios de tamaño de la metodología que se esté empleando (en este supuesto 10 días).

• Si las estimaciones resultan muy dispares el moderador con su criterio de gestión y basándose en las características del proyecto, equipo, reunión, nº de funcionalidades a evaluar. puede optar por:

• Preguntar a las personas de estimaciones extremas: ¿Por qué crees que es necesario tanto tiempo?, y ¿Por qué crees que es necesario tan poco tiempo?. Tras oir las razones, repetir la estimación.
• Dejar a un lado la estimación de esa funcionalidad y retomar al final o en otro momento las funcionalidades que no alcanzan consenso.
• Pedir al cliente o propietario del producto que descomponga la funcionalidad y valorar cada una de las nuevas funcionalidades resultantes.
• Tomar la estimación menor, mayor o la media.

Este protocolo de reunión evita los largos atascos de análisis circulares en ping-pong 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, a escasos minutos, consigue alcanzar consensos sin discusiones, y además... resulta divertido y dinamiza la reunión.