Estima esfuerzo con story points y planning poker

Concepto clave

Los story points son una unidad de medida relativa que usamos en Scrum para estimar el esfuerzo, complejidad y riesgo de una historia de usuario, en lugar del tiempo exacto. Imagina que estás organizando una mudanza: no calculas minutos para cada caja, sino que comparas "esta caja de libros pesa como 3 cajas de ropa". Así funciona: asignamos puntos relativos basados en comparaciones, no en horas.

El planning poker es la técnica colaborativa donde el equipo estima juntos usando cartas con números de la secuencia de Fibonacci (1, 2, 3, 5, 8, 13...). Esta secuencia refleja la incertidumbre: cuanto más grande la tarea, menos precisión tenemos. Es como cuando planificas un viaje: decidir qué ropa llevar (1 punto) es más fácil que organizar todo el itinerario (8 puntos).

"Los story points miden esfuerzo relativo, no tiempo absoluto. Un 5 no son 5 horas, sino 5 veces más complejo que un 1."

Cómo funciona en la práctica

Paso a paso en un sprint planning:

1. El Product Manager presenta una historia de usuario, como "Como usuario, quiero filtrar productos por precio para encontrar opciones dentro de mi presupuesto".
2. Cada miembro del equipo (desarrolladores, testers, diseñadores) selecciona en privado una carta de planning poker que represente su estimación.
3. Todos revelan sus cartas simultáneamente. Si hay consenso (ej., todos muestran 3), se asigna ese valor.
4. Si hay discrepancia (ej., cartas 3, 5, y 8), los que dieron valores extremos explican su razonamiento. Luego, se repite hasta converger.

Ejemplo con datos en una tabla:

Caso de estudio

En TechApp, un equipo de Product Management estaba desarrollando una nueva funcionalidad de notificaciones push. Estimaron estas historias:

• "Configurar servidor de notificaciones": inicialmente 8 puntos, pero tras discutir riesgos técnicos, subió a 13.
• "Diseñar interfaz de configuración": estimada en 3 puntos, basada en una tarea similar anterior de 2 puntos.
• "Probar en diferentes dispositivos": 5 puntos, por la variabilidad de sistemas operativos.

Al final del sprint, completaron 21 story points (8+3+5+5 de otra tarea), estableciendo una velocidad del equipo (puntos por sprint) para planificar mejor el siguiente. Este caso muestra cómo las estimaciones relativas ayudan a predecir capacidad, no plazos rígidos.

Errores comunes

• Convertir puntos a horas: Decir "1 punto = 8 horas" pierde el sentido relativo. Solución: Mantener la discusión en complejidad, no tiempo.
• Presionar por estimaciones bajas: Si el Product Manager influye para reducir puntos, se subestima el trabajo. Solución: El equipo técnico decide, basado en su experiencia.
• Ignorar la discrepancia: Saltarse la discusión cuando hay cartas diferentes lleva a estimaciones incorrectas. Solución: Siempre escuchar las razones de los valores extremos.
• Usar números no Fibonacci: Estimaciones como 4 o 6 pierden la incertidumbre progresiva. Solución: Adherirse a la secuencia (1,2,3,5,8,13).
• No re-calibrar: Si una tarea estimada en 3 puntos tomó mucho más, no ajustar futuras estimaciones. Solución: Revisar estimaciones pasadas en retrospectivas.

Checklist de dominio

• Entiendo que story points miden esfuerzo relativo, no tiempo absoluto.
• Puedo explicar por qué usamos la secuencia de Fibonacci para planning poker.
• He participado en una sesión donde el equipo estima colaborativamente.
• Sé cómo facilitar una discusión cuando hay discrepancias en las estimaciones.
• Reconozco al menos dos errores comunes y cómo evitarlos.
• Puedo relacionar story points con la velocidad del equipo para planificación.
• Uso estimaciones para priorizar, no para comprometer fechas exactas.

Estimación colaborativa para una nueva funcionalidad

Practica estimando story points con planning poker para un proyecto realista. Sigue estos pasos:

1. Contexto: Eres Product Manager en una app de fitness. El equipo debe desarrollar la funcionalidad "Registro de entrenamientos diarios".
2. Prepara las historias: Escribe 3 historias de usuario en formato "Como [rol], quiero [objetivo] para [beneficio]". Ejemplo: "Como usuario, quiero ingresar mi tiempo de ejercicio para ver mi progreso semanal".
3. Estima individualmente: Para cada historia, asigna story points (usa 1,2,3,5,8,13) basado en complejidad relativa. Anota tu razonamiento.
4. Simula discusión: Imagina que en un equipo, las estimaciones para una historia fueron 3, 5, y 8. Escribe un breve diálogo donde los miembros explican sus puntos de vista y llegan a un consenso.
5. Calcula velocidad: Si el equipo completó 15 story points en el último sprint, ¿cuántas de tus historias estimadas podrían caber en el próximo? Justifica.

• Piensa en dependencias técnicas: ¿la historia requiere integración con APIs externas?
• Compara con una tarea base: si "login de usuario" fue 3 puntos, ¿esta es más o menos compleja?
• Considera riesgos: ¿hay incertidumbre en el diseño o pruebas?

Evalua tu comprension

Completa el quiz interactivo de arriba para ganar XP.