Técnicas de estimación: Planning Poker y Story Points

Técnicas de Estimación: Planning Poker y Story Points

En el ámbito de Scrum y las metodologías ágiles, la estimación precisa del trabajo es fundamental para entregar valor de manera consistente. Dos técnicas que han demostrado su efectividad son los Story Points y el Planning Poker. En esta lección aprenderás cómo aplicarlas correctamente en tus sprints.

¿Por qué necesitamos estimar en ágil?

Antes de sumergirnos en las técnicas, es importante entender el por qué detrás de la estimación ágil. A diferencia de los métodos tradicionales donde estimamos en horas, en ágil trabajamos con relative sizing (tamaño relativo). Esto se debe a que:

• Las horas son difíciles de predecir con precisión para tareas desconocidas
• Los equipos tienden a ser optimistas cuando estiman en horas
• El tamaño relativo es más fácil de comparar que magnitudes absolutas
• Permite mantener la consistencia entre diferentes miembros del equipo

Story Points: El Qué y el Porqué

Los Story Points son una unidad de medida que representa el tamaño relativo de un elemento del backlog. No representan horas de trabajo, sino una combinación de factores:

• Complejidad: ¿Qué tan difícil es técnicamente?
• Esfuerzo: ¿Cuánto trabajo implica?
• Incertidumbre: ¿Cuántos riesgos o unknowns hay?
• Historia: ¿Hay trabajo previo similar como referencia?

La Escala de Fibonacci Ajustada

La escala más utilizada para Story Points es la secuencia de Fibonacci: 1, 2, 3, 5, 8, 13, 21, 40, 100. Esta escala tiene una característica importante: los espacios entre números crecen exponencialmente, lo que refleja la incertidumbre inherente a medida que las historias se hacen más grandes.

"Una historia de 5 puntos NO debería tomar exactamente 5 horas o 5 días. Es simplemente un poco más grande que una de 3 puntos y un poco más pequeña que una de 8 puntos."

Planning Poker: Estimación Colaborativa

El Planning Poker es una técnica de estimación en grupo que promueve la participación de todo el equipo y reduce el sesgo de confirmación. Fue popularizada por Mike Cohn en su libro "Agile Estimating and Planning".

¿Cómo funciona el Planning Poker?

El proceso es elegante en su simplicidad:

1. El Product Owner presenta la historia de usuario y responde preguntas del equipo
2. Cada miembro del equipo selecciona en secreto una carta con el número de Story Points que considera apropiado
3. Cuando todos han seleccionado, revelan sus cartas simultáneamente
4. Si hay consenso (todos eligieron lo mismo), se asigna ese valor
5. Si hay divergencia, las personas con valores extremos explican su razonamiento
6. Se repite el proceso hasta alcanzar consenso o un rango aceptable

El Rol de las Tarjetas

Las cartas de Planning Poker típicamente incluyen:

0  |  ½  |  1  |  2  |  3  |  5  |  8  |  13  |  20  |  40  |  100  |  ?  |  ☕

Donde cada símbolo significa:

• ?: "No tengo idea, necesito más información"
• ☕: "Necesito un descanso antes de continuar"
• 0: La tarea ya está hecha o es trivially simple
• 100: Esta historia es enorme, probablemente debería dividirse

Ejemplo Práctico: Estimando una Historia de Usuario

Imaginemos que el equipo está estimando una historia de usuario para un sistema de e-commerce:

HU-023: Como cliente, quiero poder guardar múltiples direcciones de envío para no tener que ingresarlas cada vez.

El equipo discute y considera:

• Desarrollador Senior: "Es una tabla relacionada, endpoint CRUD, y修改 en el checkout. Parece straightforward, pero hay validaciones de formato."
• Diseñadora UX: "Necesitamos cambiar el formulario actual y añadir un selector de direcciones. Hay varios edge cases como direcciones internacionales."
• QA: "Hay que probar múltiples escenarios: default, edición, eliminación de la dirección activa, etc."

Después de la discusión, el equipo vota. Las cartas reveladas muestran: 3, 3, 5, 5, 8. La persona que votó 8 explica que hay complejidad adicional con validaciones internacionales. Después de discutir este punto, el equipo llega a consenso en 5 Story Points.

Estableciendo el Velocidad del Equipo

Después de completar algunos sprints, el equipo puede calcular su velocidad: la suma de Story Points completados en un sprint. Esta velocidad se convierte en la herramienta principal para:

• Planificar la capacidad: "Si nuestra velocidad es 35 puntos, ¿cuántas historias podemos tomar?"
• Predecir fechas de entrega: "Con 40 puntos por sprint, ¿cuántos sprints necesitamos?"
• Detectar tendencias: ¿La velocidad está creciendo, estable o decreciendo?

Importante: Nunca compares la velocidad entre equipos. Cada equipo tiene su propia escala de referencia y lo que es 5 puntos para uno puede ser 8 para otro.

Planning Poker Remoto y Digital

En equipos distribuidos o trabajando remotamente, existen herramientas digitales que facilitan el Planning Poker:

• PlanitPoker: Herramienta gratuita de ThoughtWorks
• Scrum Poker: App disponible para móviles
• Integraciones en Jira/Confluence: Plugins que permiten votaciones sincrónicas
• Video llamada + documento compartido: Solución simple y efectiva

Factores que Mejoran la Precisión

Para que tus estimaciones sean más precisas a lo largo del tiempo:

1. Historias de usuario pequeñas: Stories más pequeñas son más fáciles de estimar
2. Criterios de aceptación claros: Reduce la ambigüedad que causa variaciones
3. Revisiones de estimación: Después del sprint, compara estimado vs completado
4. Refinamiento continuo: No esperes al Planning para entender las historias
5. Participación del equipo completo: Todos los roles aportan perspectivas diferentes

Errores Comunes en Estimación Ágil

Error 1: Estimar en horas disfrazadas

Usar Story Points pero pensar en horas ("esta es de 5 porque son 5 horas"). Esto derrota el propósito del relative sizing y genera frustración cuando las estimaciones "no cuadran" con la realidad.

Error 2: No dividir las historias grandes

Intentar estimar historias de 21+ puntos sin dividirlas. Las historias grandes son inherentemente más difíciles de estimar. Si una historia parece muy compleja, probablemente debería dividirse en varias más pequeñas.

Error 3: Dejar que el manager o PO dicte las estimaciones

El equipo técnico es quien debe estimar. Si el Product Owner influye demasiado, el equipo pierde propiedad sobre el proceso y las estimaciones pierden objetividad.

Cuándo Usar Cada Técnica

Ambas técnicas se complementan:

• Planning Poker: Ideal para Sprint Planning cuando el equipo completo está disponible. Promueve discusión y alineación.
• Story Points: Se usan como unidad de medida tanto en Planning Poker como en otras técnicas como T-Shirt Sizing o Dot Voting.

También existen otras técnicas de estimación que puedes explorar: T-Shirt Sizing (XS, S, M, L, XL) para kick-offs de quarter, Dot Voting para priorización rápida, o affinity grouping para organizar grandes cantidades de historias.

Checklist de Dominio

Antes de considerar que dominas estas técnicas, verifica que puedes:

• Explicar la diferencia entre estimar en horas vs Story Points y por qué preferimos estos últimos
• Facilitar una sesión de Planning Poker con las reglas correctas (votación secreta, revelación simultánea)
• Calcular la velocidad de tu equipo después de al menos 3 sprints
• Aplicar la escala de Fibonacci de forma consistente
• Dividir historias de usuario grandes en incrementos más pequeños
• Reconocer y evitar los tres errores comunes mencionados
• Adaptar el Planning Poker para sesiones remotas o híbridas
• Explicar qué factores consideras al estimar (complejidad, esfuerzo, incertidumbre)
• Utilizar las estimaciones para predecir capacidad y fechas de entrega
• Identificar cuándo una historia necesita más refinamiento antes de ser estimada

Dominar estas técnicas requiere práctica. No te frustres si las primeras sesiones son torpes; con el tiempo, tu equipo desarrollará un vocabulario común de tamaños y las estimaciones se volverán más naturales y precisas.