El Planning Poker Que Sale Mal
Lunes por la mañana, reunión de planificación de sprint.
Product Owner: « Vamos a estimar la feature ‘Notificaciones Push’. »
El equipo saca las tarjetas de planning poker.
Desarrollador 1: « Creo que es un 5. »
Desarrollador 2: « No, claramente es un 8. Hay gestión de permisos en iOS, Android, web… »
Desarrollador 3: « Espera, ¿contamos solo el backend o también el frontend? »
Dev 1: « Euh… ¿ambos? »
Dev 2: « En ese caso es un 13. »
20 minutos de debate.
Product Owner: « Ok, validamos con 8 puntos. »
Seis semanas después.
Product Owner: « ¿Por qué las notificaciones no están terminadas? Estimamos 8 puntos. »
Desarrollador 1: « Sí, pero 8 puntos no son 8 días. En realidad pasamos 3 semanas en eso. »
Product Owner: « Pero… ¿para qué sirven los puntos entonces? »
Silencio incómodo.
El Problema Fundamental De Los Story Points
Los story points (puntos de complejidad) son una abstracción inventada por las metodologías Ágiles para estimar el trabajo sin hablar de tiempo.
La Ilusión de la Abstracción
La Promesa:
« Los puntos miden la complejidad, no el tiempo. Evita la presión de la gestión sobre los plazos. »
La Realidad:
- Nadie sabe qué representa un « 5 » concretamente
- Cada equipo tiene su propia escala (un 5 en el equipo A ≠ 5 en el equipo B)
- Los puntos cambian con la rotación (nuevo dev = recalibración completa)
- La gestión siempre termina convirtiendo puntos a tiempo (« tu velocidad es 40 puntos/sprint, entonces 10 días »)
Resultado: Creas una capa de abstracción innecesaria que oculta la realidad.
Las Cuatro Mentiras De Los Story Points
Mentira 1: « Los Puntos Evitan La Presión Sobre Los Plazos »
Falso.
La gestión siempre convertirá los puntos a tiempo:
- « Hacen 40 puntos por sprint de 2 semanas. »
- « Entonces 1 punto = 0,25 día. »
- « Esta feature es 20 puntos, entonces 5 días. »
Solo agregaste un paso de conversión.
En lugar de decir directamente « 5 días », dices « 20 puntos » que se transforman en « 5 días » en la cabeza de todos de todas formas.
Mentira 2: « Los Puntos Miden La Complejidad, No El Tiempo »
Falso.
Durante el planning poker, el equipo siempre piensa en tiempo:
- « Es un 5 » = « Va a tomar aproximadamente 2-3 días »
- « Es un 13 » = « Va a tomar una semana completa »
Nadie piensa en ‘unidades de complejidad abstracta’.
Los desarrolladores convierten mentalmente los puntos a tiempo, luego reconviertes los puntos a tiempo para hacer la planificación.
¿Por qué no simplemente estimar en tiempo desde el principio?
Mentira 3: « Los Puntos Permiten Comparar Issues »
Falso.
Los puntos crean una falsa comparabilidad:
- « Este issue es un 5, así que es la mitad de complejo que un 10. »
Pero en realidad:
- Un 5 puede tomar 1 día (feature simple, bien definida)
- Otro 5 puede tomar 5 días (feature « simple » pero con dependencias ocultas)
Los puntos no garantizan ninguna coherencia.
Mentira 4: « Los Puntos Se Ajustan Automáticamente Con La Experiencia »
Falso.
Con cada nuevo miembro del equipo:
- Recalibración de los puntos
- « Espera, para ti ¿qué es un 5? »
- Nuevas sesiones de planning poker para alinear el equipo
Los puntos dependen de la composición actual del equipo.
Cuando alguien se va o llega, toda tu escala se vuelve inválida.
Por Qué Sinra Usa El Tiempo (En Días)
En Sinra, abandonamos los story points por un enfoque más simple y más honesto: estimar en días.
El Tiempo Te Fuerza A Confrontar La Realidad
Estimación en puntos:
« Esta feature es 8 puntos. »
Pregunta: ¿Cuánto tiempo toma? Respuesta: « Depende de la velocidad, del equipo, del sprint… »
Estimación en tiempo:
« Esta feature tomará 3 días. »
Pregunta: ¿Cuánto tiempo toma? Respuesta: « 3 días. »
Beneficio: Sin abstracción. Sin conversión mental. Confrontas directamente tu estimación con la realidad.
El Tiempo Revela Features Mal Descompuestas
Regla Sinra: Si no puedes estimar un issue en días, es demasiado grande.
Escenario típico:
Desarrollador: « No puedo estimar eso. Es entre 5 y 15 días. »
Product Owner: « ¿Por qué esta incertidumbre? »
Desarrollador: « Porque hay 10 cosas diferentes en este issue: backend, frontend, tests, migración de datos, documentación… »
Solución Sinra: Descompón.
Crea 5 issues separados:
- Backend API: 2 días
- Frontend UI: 1,5 días
- Tests automatizados: 1 día
- Migración de datos: 3 días
- Documentación: 0,5 día
Total: 8 días (con visibilidad clara en cada componente)
Resultado:
- ✅ Estimaciones precisas
- ✅ Seguimiento granular
- ✅ Identificación rápida de bloqueos
El Tiempo Permite La Gestión De Carga Real
Con los puntos:
- « Marc tiene 20 puntos para hacer este sprint. »
- Pero ¿cuántas horas representa? No lo sabes.
Con el tiempo (Sinra):
- « Marc tiene 6 días de trabajo asignados este sprint (10 días hábiles disponibles). »
- Le quedan 4 días para bugs, reuniones, imprevistos.
Beneficio: Sabes exactamente cuánta capacidad tiene cada desarrollador, en unidades concretas.
Puedes:
- ✅ Equilibrar la carga entre desarrolladores
- ✅ Identificar sobrecargas antes de que se conviertan en crisis
- ✅ Hacer pronósticos confiables (« A este ritmo, entregamos en 3 semanas »)
El Tiempo Es Universal
Los puntos:
- El equipo A estima en Fibonacci (1, 2, 3, 5, 8, 13…)
- El equipo B estima en potencias de 2 (1, 2, 4, 8, 16…)
- La gestión no entiende nada
El tiempo:
- Todos entienden « 3 días »
- El CTO entiende
- El CEO entiende
- El cliente entiende
- El equipo entiende
Beneficio: No necesitas explicar tu sistema de estimación. El tiempo es una unidad universal.
El Tiempo Fuerza La Responsabilidad
Con los puntos:
« Estimé 5 puntos, pero tomó más tiempo del esperado. »
Con el tiempo:
« Estimé 2 días, pero me tomó 4 días. »
La diferencia es inmediata. Confrontas la estimación con lo real.
Cuando estimas en días:
- Eres más prudente (« 2 días » suena más vinculante que « 5 puntos »)
- Descompones mejor (« 10 días es demasiado, debo cortar »)
- Aprendes de tus errores (« Subestimé en 100%, voy a ajustar »)
Resultado: Tus estimaciones mejoran con el tiempo.
El Tiempo Permite Pronósticos Confiables
Con los puntos:
- Velocidad sprint 1: 35 puntos
- Velocidad sprint 2: 42 puntos
- Velocidad sprint 3: 28 puntos
Pregunta: ¿Cuándo entregamos la feature de 60 puntos? Respuesta: « Depende… ¿entre 1,5 y 2,5 sprints? »
Con el tiempo (Sinra):
- Sprint 1: 7 días entregados de 10 planificados (70% de capacidad usada)
- Sprint 2: 8 días entregados de 10 planificados (80%)
- Sprint 3: 6,5 días entregados de 10 planificados (65%)
Promedio: 72% de capacidad usada
Feature estimada: 15 días
Cálculo de pronóstico: 15 días / 0,72 = 20,8 días calendarios = 2,1 sprints
Beneficio: Pronósticos basados en datos reales y objetivos.
Las Seis Ventajas Del Tiempo Sobre La Complejidad
1. Capacidad Exacta Y Visible
Puntos: Abstracción borrosa Tiempo: Unidades concretas
Sabes exactamente cuántos días de trabajo están asignados a cada persona.
2. Pronósticos Confiables
Puntos: Conversión mental aleatoria Tiempo: Cálculo directo
« 15 días estimados + 70% de capacidad = 21 días calendarios. »
3. Descomposición Forzada
Puntos: Puedes estimar « 13 » sin descomponer Tiempo: « 10+ días » te fuerza a cortar
Si no puedes estimar en días, descompón.
4. Universalidad
Puntos: Escala única de equipo Tiempo: Comprensible por todos
La gestión, los clientes, los stakeholders entienden « 3 días ».
5. Comparabilidad
Puntos: No comparable entre equipos Tiempo: Comparable en todas partes
Puedes comparar la velocidad entre proyectos y equipos (« equipo A entrega 6 días/sprint, equipo B entrega 8 días/sprint »).
6. Mejora Continua
Puntos: Dificultad para medir la mejora Tiempo: Métricas claras
« Antes estimábamos con 50% de error. Ahora 20%. »
Objeciones Comunes (Y Respuestas)
Objeción 1: « El Tiempo Pone Demasiada Presión En El Equipo »
Respuesta: No, las malas estimaciones ponen presión.
Cuando estimas en puntos:
- Creas una falsa sensación de precisión
- La gestión convierte los puntos a tiempo de todas formas
- El equipo se sorprende cuando la realidad no coincide
Cuando estimas en tiempo:
- Eres honesto desde el principio
- Puedes ajustar tus estimaciones con la experiencia
- Confrontas las expectativas con la realidad antes de empezar
La presión viene de la desconexión entre expectativas y realidad, no de la unidad de estimación.
Objeción 2: « Cada Desarrollador Trabaja A Un Ritmo Diferente »
Respuesta: Cierto. Pero también es cierto con los puntos.
Un desarrollador junior estimará « 5 puntos » para una tarea que un senior hará en « 2 puntos ».
La diferencia con el tiempo:
- Sabes quién estima
- Puedes ajustar según el desarrollador asignado
- Puedes medir la mejora individual
Con Sinra:
- Marc (senior) estima 2 días → toma 2,5 días (125%)
- Sophie (mid) estima 2 días → toma 3 días (150%)
- Thomas (junior) estima 2 días → toma 4 días (200%)
Aprendes los coeficientes de cada uno y ajustas tus pronósticos.
Objeción 3: « No Podemos Estimar Con Precisión En Días »
Respuesta: Esa es exactamente la señal de que el issue es demasiado grande.
Si dices:
« No sé si es 2 días u 8 días »
Entonces descompón.
Crea issues más pequeños:
- Backend: 1,5 días
- Frontend: 2 días
- Tests: 1 día
- Integración: 1,5 días
Total: 6 días (con mejor visibilidad)
El tiempo fuerza la descomposición. Es una característica, no un bug.
Objeción 4: « Los Story Points Evitan Debates Sobre Los Plazos »
Respuesta: No, los posponen.
Con los puntos:
- El equipo estima 40 puntos
- La gestión pregunta « ¿Cuánto tiempo toma? »
- Conviertes: « Aproximadamente 2 semanas »
- Gestión: « ¿Por qué no 1 semana? »
Con el tiempo:
- El equipo estima 8 días
- Gestión: « ¿Por qué no 4 días? »
- Explicas: « Porque hay X, Y, Z para hacer »
El debate ocurre de todas formas. Mejor ser directo.
Objeción 5: « Los Puntos Se Ajustan Automáticamente Con La Velocidad »
Respuesta: Falso. La velocidad fluctúa enormemente.
Velocidad sprint 1: 35 puntos Velocidad sprint 2: 42 puntos (un dev estaba de vacaciones en sprint 1) Velocidad sprint 3: 28 puntos (muchos bugs en producción)
Los puntos no se ajustan. Debes recalibrar manualmente todo el tiempo.
Con el tiempo:
- Sprint 1: 7 días entregados / 10 disponibles = 70%
- Sprint 2: 8 días entregados / 8 disponibles (1 dev de vacaciones) = 100%
- Sprint 3: 6 días entregados / 10 disponibles (bugs) = 60%
Promedio: 77% de capacidad efectiva
Puedes medir objetivamente tu capacidad real.
Sinra En Acción: Tiempo vs Complejidad
Ejemplo Real: Feature « Exportar PDF »
Enfoque De Puntos (Antes De Sinra)
Planning Poker:
- El equipo debate 30 minutos
- Estimación final: 8 puntos
Entrega:
- Tiempo real: 12 días
- ¿Por qué el retraso? « Subestimamos la complejidad del layout del PDF. »
Retrospectiva:
- « Deberíamos estimar más amplio. »
- « ¿Tal vez 13 puntos la próxima vez? »
Problema: Sin aprendizaje concreto. Ajustas una abstracción.
Enfoque De Tiempo (Con Sinra)
Estimación inicial:
- Product Owner: « ¿Cuánto estimamos para exportar PDF? »
- Desarrollador: « No puedo estimar eso en un bloque. Necesitamos descomponer. »
Descomposición:
- Generar PDF simple (texto): 1,5 días
- Agregar imágenes y layout: 2 días
- Manejar tablas complejas: 2,5 días
- Optimizar rendimiento (documentos grandes): 1,5 días
- Tests y casos límite: 1,5 días
Total estimado: 9 días
Entrega:
- Tiempo real: 11 días
- ¿Por qué el retraso? El layout de las tablas tomó 3,5 días en lugar de 2,5.
Retrospectiva:
- « Subestimamos sistemáticamente los layouts complejos. »
- « Próxima feature con layout: agregar +1 día de buffer. »
Beneficio: Aprendizaje concreto y accionable.
Las Tres Reglas Sinra Para Estimar En Tiempo
Regla 1: Estima En Días (No En Horas)
¿Por qué?
- Las horas dan una falsa sensación de precisión
- Nadie trabaja 8 horas productivas por día (reuniones, bugs, interrupciones)
- Los días son más fáciles de comunicar
Granularidad:
- 0,5 día (medio día)
- 1 día
- 1,5 días
- 2 días
- etc.
Evita:
- « 3,75 días » (demasiado preciso, irreal)
- « 0,25 día » (demasiado pequeño, crea un issue separado)
Regla 2: Si No Puedes Estimar, Descompón
Señal de alerta:
« Es entre 3 y 10 días. »
Acción: Descompón en issues más pequeños hasta que la incertidumbre desaparezca.
Objetivo: Cada issue debe ser estimable con ±50% de precisión.
Ejemplo:
- ❌ « Implementar notificaciones: 5-15 días »
- ✅ « Backend API de notificaciones: 2 días »
- ✅ « Frontend UI de notificaciones: 1,5 días »
- ✅ « Notificaciones push móviles: 3 días »
Regla 3: Confronta Tus Estimaciones Con Lo Real
Después de cada issue:
- Tiempo estimado: 2 días
- Tiempo real: 3,5 días
- Brecha: +75%
Acción: Identifica por qué.
- ¿Dependencia imprevista?
- ¿Complejidad subestimada?
- ¿Bugs bloqueantes?
Ajusta tus estimaciones futuras en consecuencia.
Resultado: Tus estimaciones mejoran sprint tras sprint.
Comparación: Planning Poker vs Estimación De Tiempo Sinra
| Aspecto | Planning Poker (Story Points) | Estimación De Tiempo (Sinra) |
|---|---|---|
| Unidad | Puntos abstractos (1, 2, 3, 5, 8, 13…) | Días (0,5d, 1d, 1,5d, 2d…) |
| Comprensión | Requiere calibración de equipo | Universal, inmediatamente entendido |
| Conversión | Puntos → tiempo (mental o explícito) | Ya en tiempo |
| Gestión de carga | Abstracto (« 20 puntos este sprint ») | Concreto (« 8 días de 10 disponibles ») |
| Pronósticos | Basados en velocidad fluctuante | Basados en capacidad real |
| Descomposición | Puede permanecer vago (« 13 puntos ») | Fuerza descomposición (« 10+ días = demasiado grande ») |
| Comparabilidad | No comparable entre equipos | Comparable universalmente |
| Rotación | Recalibración completa necesaria | Impacto mínimo |
| Mejora | Difícil de medir | Métricas claras |
| Transparencia | Opaca para stakeholders | Transparente para todos |
Los Cinco Signos De Que Deberías Abandonar Los Story Points
Signo 1: Conviertes Sistemáticamente Los Puntos En Tiempo
Si tu proceso se parece a:
- Estimar en puntos
- Multiplicar por tu « coeficiente » para obtener días
- Usar días para planificar
Estás desperdiciando tu tiempo. Estima directamente en días.
Signo 2: El Planning Poker Dura Más De 5 Minutos Por Issue
Si cada estimación desencadena un debate de 20 minutos (« ¿Es un 5 o un 8? »), estás optimizando la métrica equivocada.
El objetivo no es la estimación perfecta. Es una estimación útil.
Signo 3: Tus Pronósticos Siempre Son Incorrectos
Si dices regularmente:
« Pensamos entregar en 2 sprints, finalmente tomó 4 sprints »
Tus estimaciones en puntos no te ayudan a pronosticar.
Signo 4: Los Stakeholders No Entienden Tu Velocidad
Si la gestión constantemente te pregunta:
« Tu velocidad es 40 puntos/sprint. ¿Qué significa eso concretamente? »
Creaste una abstracción innecesaria.
Signo 5: Cada Nuevo Miembro Disrumpe Tu Escala
Si la contratación de un desarrollador junior o senior te obliga a recalibrar todos tus puntos, tu sistema de estimación no es robusto.
Ejemplo Real: TechFlow Cambia A Estimación De Tiempo
TechFlow (equipo de 15 personas, plataforma de automatización de marketing)
Nota: TechFlow es una empresa real que hemos anonimizado con un nombre ficticio para proteger su confidencialidad.
Antes De Sinra: Story Points Y Planning Poker
Problemas:
- Planning poker: 45 minutos por sprint para estimar 10-15 issues
- Velocidad fluctuante: 32-48 puntos por sprint (variación del 50%)
- Pronósticos incorrectos: 60% de los lanzamientos retrasados
- Debates sin fin: « ¿Es un 5 o un 8? »
- Rotación: Cada nuevo dev requería 2 sprints de recalibración
Incidente Revelador: Feature « API Webhooks » estimada en 13 puntos. Velocidad promedio: 40 puntos/sprint. Pronóstico: « 1/3 de sprint = 3-4 días. »
Realidad: 18 días (3,5 semanas).
¿Por qué? Los 13 puntos ocultaban:
- 5 endpoints diferentes
- Gestión de retry + cola
- Tests de integración complejos
- Documentación de API
Nadie sabía qué representaba realmente « 13 puntos ».
Después De Sinra: Estimación En Tiempo
Cambios:
- Abandono del planning poker
- Estimación directa en días
- Descomposición forzada si >3 días
- Seguimiento tiempo estimado vs tiempo real
Feature « API Webhooks » (Versión Tiempo): En lugar de « 13 puntos », descomposición en:
- Endpoint de creación de webhook: 1,5 días
- Endpoints de lista/actualización/eliminación: 1 día
- Sistema de reintentos: 2 días
- Gestión de cola: 2,5 días
- Tests de integración: 2 días
- Documentación OpenAPI: 1 día
Total estimado: 10 días
Entrega real: 12 días
Brecha: +20% (en lugar de +350% con los puntos)
Resultados (Después De 6 Meses)
Antes (Story Points):
- Tiempo de planning poker: 45 min/sprint
- Confiabilidad de estimaciones: 40% (60% retrasado)
- Velocidad: Fluctuante (32-48 puntos)
- Pronósticos de lanzamiento: Incorrectos 6 de 10 veces
Después (Tiempo):
- Tiempo de estimación: 15 min/sprint
- Confiabilidad de estimaciones: 75% (±25% error)
- Capacidad: Estable (7-8 días/sprint)
- Pronósticos de lanzamiento: Confiables 8 de 10 veces
Cita Del Lead Developer:
« Antes, pasábamos 45 minutos debatiendo si era un 5 o un 8. Ahora decimos ‘2 días’ y seguimos adelante. Triplicamos nuestra eficiencia de planificación. »
Cita Del Product Manager:
« Con los puntos, nunca sabía cuándo íbamos a entregar. Ahora puedo decir ‘en 3 semanas’ con 80% de confianza. Los stakeholders lo aman. »
Cómo Cambiar De Story Points A Tiempo
Paso 1: Analiza Tus Datos Históricos
Acción:
- Toma tus últimos 5 sprints
- Para cada issue: puntos estimados vs tiempo real
- Calcula tu ratio promedio (ex: 1 punto = 0,5 día)
Beneficio: Tienes una línea de base de conversión.
Paso 2: Anuncia El Cambio Al Equipo
Comunicación:
« A partir del próximo sprint, estimamos directamente en días en lugar de puntos. ¿Por qué? Porque nos permite planificar mejor y hacer pronósticos confiables. »
Anticipa objeciones: (ver sección Objeciones arriba)
Paso 3: Estima Tu Primer Sprint En Tiempo
Reglas:
- Estima en días (0,5d, 1d, 1,5d, 2d…)
- Si >3 días: descompón
- Si incertidumbre >50%: descompón
Ejemplo:
- Issue A: 1,5 días
- Issue B: 2 días
- Issue C: descompuesto en C1 (1d) + C2 (1,5d) + C3 (0,5d)
Paso 4: Sigue Estimado vs Real
Después de cada issue:
- Tiempo estimado: X días
- Tiempo real: Y días
- Brecha: (Y - X) / X
Aprende de tus errores:
- ¿Qué tipos de issues subestimas?
- ¿Qué desarrolladores necesitan coeficientes de ajuste?
Paso 5: Ajusta Progresivamente
Sprint 1: Error promedio +40% Sprint 2: Error promedio +25% Sprint 3: Error promedio +15%
Tus estimaciones mejoran naturalmente.
Puntos De Acción: Adoptar La Estimación De Tiempo
- Calcula tu ratio actual: 1 punto = ¿cuántos días? (analiza tus últimos 5 sprints)
- Estima tu próximo sprint en días: abandona los puntos para un sprint de prueba
- Descompón issues grandes: si >3 días estimados, divide en issues más pequeños
- Sigue estimado vs real: mide tus brechas y aprende
- Ajusta tus pronósticos: usa tu % de error promedio para afinar los plazos
El Punto Clave
Los story points crean una abstracción que aleja los equipos de la realidad.
Estimas en puntos, conviertes mentalmente a tiempo, planificas en tiempo, luego descubres que la realidad no coincide.
El tiempo (en días) confronta tus estimaciones con la realidad.
Sin abstracción. Sin conversión. Sin calibración de equipo. Sin debates interminables.
Solo una estimación honesta, verificable, y que mejora con la experiencia.
Resultado:
- ✅ Capacidad exacta y visible
- ✅ Pronósticos confiables
- ✅ Descomposición forzada de features complejas
- ✅ Universalidad (comprendida por todos)
- ✅ Mejora continua medible
El tiempo no miente. Los story points, sí.
¿Listo para abandonar los story points y planificar con datos reales? Inicia una prueba gratuita de Sinra →
Descubre la gestión de proyectos donde las estimaciones confrontan la realidad, no donde la ocultan.