Piensa esto por un momento: tienes planeado mirar una película en la comodidad de tu casa, y deseas palomitas y soda ¿Cuánto tiempo tardarías en ir a la tienda más cercana y regresar a casa para mirar tu película? Anota tu respuesta.

Ahora puedes dirigirte a la tienda a realizar tus compras y medir el tiempo que tardaste en realidad. Debes ser muy observador en los detalles que ocurren durante la ruta. Anota el tiempo final y los hechos que alteraron los resultados de tu predicción. 

Ahora realizaremos este ejercicio de nuevo, pero ahora debes interrogar a las personas que viven contigo. El procedimiento es el siguiente: 

1. Plantea la cuestión: ir a comprar palomitas y soda a la tienda más cercana. 
2. En privado anotar en un papel el tiempo en minutos que les tomaría hacer la compra.
3. Una vez que todos anotaron su estimación, la mostrarán al resto de los participantes.
4. Si los resultados tiene una secuencia como 10,13,15,18 entonces debes obtener la media. Para este ejemplo 14 minutos.
5. Si existe mucha distancia entre las estimaciones, por ejemplo 3, 15, 17, 30, entonces cada participante deberá exponer la razón de su estimación con el grupo. 
6. Una vez expuesta la razón de la estimación se repetirá la estimación (pasos 1, 2, 3, 4 y 5).
7. Una vez que tengas la estimación final podrás comparar con el tiempo real que tomó realizar la compra. Es muy probable que esa estimación este muy cercana a la realidad.

Al método anterior se le conoce como inteligencia colectiva, y el resultado puede ser una estimación exacta sí interrogas al número suficiente de personas (alrededor de 800).

Somos muy malos para realizar estimaciones exactas, ya que consideramos siempre los escenarios ideales. Puede ocurrir que la tienda más cercana estaba cerrada, o que no aceptaban tarjeta de crédito, o que no tenían palomitas de maíz o que había muchas personas esperando para pagar sus compras, o quizá tuviste que ir en auto y perdiste tiempo en el estacionamiento o en el tránsito. 

En una actividad tan simple como una compra existen muchas situaciones que no consideraste al hacer tu estimación, y esto altera los resultados de tu predicción… ¡imagina lo complicado que es realizar una estimación para desarrollar un producto de software que llevará algunos meses!

En el método tradicional para el desarrollo de productos de software (método en cascada) la estimación es hecha por el líder de proyecto o líder técnico y expertos ideales, no por quién realmente realizará el trabajo. Esta es una de las razones más comunes por la que las estimaciones en tiempo fallan.

En Scrum se cuenta con una estimación simple, a través de tamaño relativo (chico, mediano, grande, extra grande). A esta se le conoce como Póker de planeación.

1. La idea es muy sencilla. Cada persona dentro del equipo de desarrollo recibe un mazo de naipes con los números de Fibonacci: 1, 2, 3, 5, 8 y 13. Luego cada tarea por calcular se pone sobre la mesa. Todos tiran entonces la carta que creen que representa la cantidad de esfuerzo correcta y la ponen bocabajo.
2. Después, todos la voltean al mismo tiempo. Si la secuencia resultante es de números sucesivos (5, 8, 8, 13), el equipo calcula la media (promedio).
3. Si la distancia entre dos números es de más de tres cartas, quienes tiraron los naipes respectivos explican sus razones, tras lo cual se juega otra ronda. De lo contrario se promedian las estimaciones.

Es crucial que la estimación corra a cargo del equipo que llevará a cabo el trabajo, no de expertos ideales. Esta estimación se realiza durante el Sprint planning y después de haber clarificado la historia de usuario con el product owner, sus criterios de aceptación y definición de hecho, de esta manera las estimaciones serán más precisas. Durante las actividades de refinamiento del product backlog también se usa el póker de planeación.

Los puntos resultantes de esta estimación no significan nada, es decir, no son horas, ni días. Simplemente es una manera de dimensionar el esfuerzo que implica para el equipo de desarrollo cada actividad. Estos puntos se utilizan después para elaborar un diagrama de finalización, burndown chart, y finalmente para calcular la velocidad del equipo.

Si el equipo ha pasado por varios Sprints, este debe considerar el número de puntos que acumulo en el Sprint más reciente, este número se considera la velocidad del equipo y debería ser aumentar cada Sprint.

El uso del Póker de Planeación en Scrum ofrece varios beneficios clave:

1. Consenso Rápido: Facilita la obtención de consenso rápido entre los miembros del equipo sobre la complejidad y esfuerzo requerido para las tareas.

2. Participación Activa: Incentiva la participación activa de todos los miembros del equipo, promoviendo una comprensión colectiva de las historias de usuario o tareas.

3. Transparencia: Proporciona visibilidad y transparencia al proceso de estimación, permitiendo que todos comprendan las razones detrás de las estimaciones dadas.

4. Reducción de Sesgos: Ayuda a mitigar sesgos individuales al limitar la influencia de opiniones fuertes, promoviendo discusiones y ajustes basados en el consenso del equipo.

5. Eficiencia en Estimación: Agiliza el proceso de estimación al proporcionar un método estructurado y ágil para evaluar el tamaño relativo de las tareas.

6. Feedback Continuo: Facilita la comunicación continua y el intercambio de ideas, fomentando un entorno de aprendizaje donde el equipo mejora sus habilidades de estimación con el tiempo.

En resumen, el Poker de Planeación en Scrum no solo es una herramienta de estimación, sino también una práctica que promueve la colaboración y mejora continua en el equipo de desarrollo.

¡Hasta la próxima!