Cómo funciona planning poker
Planning poker es una técnica de estimación basada en consenso donde cada miembro del equipo vota simultáneamente usando cartas con números de la secuencia Fibonacci (1, 2, 3, 5, 8, 13, 21). Los números no son horas, son story points: unidades abstractas que representan esfuerzo, complejidad y riesgo combinados.
El proceso: alguien presenta una tarea, el equipo hace preguntas, todos eligen una carta en secreto, revelan simultáneamente. Si hay consenso, ese es el puntaje. Si hay disparidad (ej: un 3 y un 13), los extremos explican su razonamiento y se vuelve a votar. La clave es la conversación: un dev puede ver complejidad técnica que otros no, o QA identifica casos borde que aumentan el esfuerzo.
¿Por qué Fibonacci? Los gaps crecientes reflejan incertidumbre: distinguir entre 1 y 2 puntos es fácil, pero entre 13 y 15 no tiene sentido porque a esa escala la precisión es imposible. Si algo parece más de 13, probablemente debas dividirlo en tareas más chicas.
De story points a horas reales
Story points no son horas, pero eventualmente necesitás traducirlos a calendario. Cada equipo tiene su propia velocidad: puntos completados por sprint. Si en un sprint de 2 semanas completás 40 puntos y tenés 4 devs, tu velocidad es ~10 puntos/dev/sprint, o ~1.25 puntos/dev/día.
Para convertir puntos a horas, usá tu histórico. Si 1 punto suele tomar 2-4 horas, 5 puntos son 10-20 horas (1-2.5 días). Pero ojo: esto es un promedio. Un 5 en backend puede ser 12 horas; un 5 en frontend puede ser 8. El contexto importa: ¿hay código legacy? ¿Equipo nuevo? ¿Dependencias externas? Agregá buffer.
Error común: convertir mecánicamente puntos a horas ('1 punto = 1 hora') ignora que los puntos incluyen testing, code review, refactor, reuniones. Una tarea de 3 puntos raramente son 3 horas de coding puro; son 3 puntos de esfuerzo total, que pueden ser 6-10 horas de calendario considerando interrupciones y overhead.
Factores que afectan la estimación
La complejidad técnica es obvia: integrar una API externa con documentación pobre es más que copiar un componente existente. Pero hay factores menos visibles: contexto del equipo (¿alguien ya hizo algo similar?), calidad del diseño (mockups claros vs 'hacelo lindo'), claridad de requisitos (criterios de aceptación concretos vs 'algo como X').
El riesgo multiplica esfuerzo. Una tarea con dependencia de un servicio externo inestable puede ser técnicamente simple pero arriesgada: merece más puntos por el tiempo potencial de debugging. Lo mismo con cambios en código legacy sin tests: el coding es rápido, pero validar que no rompiste nada lleva tiempo.
El estado del equipo también cuenta. ¿Estás en modo 'sprint normal' o en 'todos en calls con stakeholders'? ¿Hay vacaciones planificadas? ¿Onboarding de alguien nuevo que hará pair programming? Una tarea de 5 puntos puede expandirse a 8 si sabés que vas a estar enseñando mientras la hacés. La honestidad en estos factores mejora las estimaciones.
Cuándo revisar y re-estimar
Estimaciones no son contratos inmutables. Si arrancás una tarea de 5 puntos y a las 2 horas descubrís que la API que ibas a usar está deprecada, pará y re-estimá. Mejor comunicar temprano 'esto va a ser 8, no 5' que sorprender en la review con 'me llevó el doble'.
En retrospectiva, compará estimaciones vs tiempo real. Si constantemente subestimás, tu escala está mal calibrada: lo que considerás 3 puntos es en realidad 5 para tu contexto. Ajustá en futuros sprints. Si sobreestimás siempre, estás siendo demasiado conservador (o mejoraste mucho y no actualizaste tu baseline).
Tareas que consistentemente explotan (estimadas en 5, terminan siendo 13) son señal de problema: requisitos poco claros, deuda técnica oculta, o scope creep. No es un problema de estimación, es un problema de definición. Usá esos datos en refinement para pedir más claridad o dedicar un sprint a limpiar la base de código antes de seguir.