Story points consistentes: crea una escala de referencia, no una cifra perfecta
En muchos refinamientos el problema no es que el equipo no sepa estimar. El problema es que cada persona está usando una escala distinta. Para una persona, 5 puntos significa “me lleva dos días”.
Publicado el
En muchos refinamientos el problema no es que el equipo no sepa estimar. El problema es que cada persona está usando una escala distinta.
Para una persona, 5 puntos significa “me lleva dos días”. Para otra, “hay integración con un sistema externo”. Para otra, “no sabemos suficiente”. Cuando esas interpretaciones se mezclan, el planning poker deja de ayudar y se convierte en una negociación de números.
Los story points funcionan mejor cuando se usan como estimación relativa: no intentan predecir horas exactas, sino comparar una historia con otras ya entendidas por el equipo. Atlassian los presenta como una forma de estimar esfuerzo considerando factores como complejidad, volumen de trabajo e incertidumbre. La clave práctica está ahí: si el equipo no comparte qué significa “más complejo” o “más incierto”, la escala se vuelve inestable.
Esta guía propone un enfoque sencillo: construir una pequeña escala de referencia viva para que cada voto tenga un punto de comparación común. No elimina la conversación, pero la hace más concreta.
1. Deja de preguntar “cuántos puntos tiene” y pregunta “a qué se parece”
Una estimación aislada invita a opiniones incompatibles. Una estimación comparada obliga al equipo a razonar con una referencia.
Antes de votar una historia nueva, el equipo debería poder responder:
- ¿Es más pequeña, similar o más grande que una historia que ya conocemos?
- ¿Tiene más incertidumbre que esa referencia?
- ¿Exige más perfiles, coordinación o validación?
- ¿El alcance está igual de claro o todavía hay ambigüedad?
Este cambio parece pequeño, pero reduce una confusión habitual: convertir los story points en una traducción encubierta de horas. Si cada persona calcula mentalmente duración individual, los votos dependerán de experiencia, velocidad personal o agenda. Si el equipo compara contra historias de referencia, la conversación se centra en el trabajo, no en la capacidad individual.
Un ejemplo genérico:
- Historia A: cambio visual simple, sin lógica nueva, ya se ha hecho algo parecido.
- Historia B: nuevo flujo con validación, dependencias de backend y criterios aún discutibles.
Si ambas reciben 3 puntos, el equipo necesita revisar su escala. No porque una cifra sea “incorrecta”, sino porque probablemente está mezclando esfuerzo, riesgo y claridad de forma inconsistente.
2. Construye una escala con pocas historias ancla
No hace falta documentar una enciclopedia de estimaciones. De hecho, demasiadas reglas suelen volver la escala rígida. Basta con elegir entre 3 y 5 historias ancla que el equipo entienda bien.
Una escala mínima puede incluir:
- Una historia pequeña y clara.
- Una historia media con algo de coordinación.
- Una historia grande pero todavía razonable para entrar en refinamiento.
- Opcionalmente, una historia que el equipo considera demasiado grande o incierta para estimar bien.
Para cada historia ancla, no registres solo el número. Registra por qué recibió ese número. Por ejemplo:
- “Pocos cambios, sin dependencia externa, criterios claros”.
- “Incluye frontend y backend, pero el comportamiento está definido”.
- “Hay integración y riesgo de pruebas, aunque el alcance está acotado”.
- “Demasiadas incógnitas; antes de estimar habría que dividir o aclarar”.
La utilidad está en esos criterios. El número sin explicación se olvida; el razonamiento se puede reutilizar.
Una buena escala de referencia no responde “cuánto tardaremos”, sino “qué tipo de trabajo estamos comparando”. Esa diferencia protege al equipo de dos extremos: discusiones interminables por un punto de diferencia y estimaciones rápidas pero poco comparables.
3. Calibra antes de votar, no después de discutir
Muchas sesiones empiezan directamente con la votación. Después aparecen votos dispersos y el equipo intenta reconstruir por qué. Es más eficaz invertir dos minutos antes.
Puedes usar esta secuencia:
- El Product Owner o quien tenga el contexto resume el objetivo de la historia.
- El equipo revisa criterios de aceptación y dependencias visibles.
- Alguien propone una historia ancla parecida.
- El equipo valida si la comparación tiene sentido.
- Solo entonces se vota.
La pregunta no es “¿estamos todos de acuerdo?”. La pregunta es “¿estamos comparando contra la misma referencia?”.
Esto reduce uno de los sesgos más comunes en refinamiento: votar con una interpretación privada del problema. El Agile Manifesto recuerda que las interacciones importan más que los procesos y herramientas. Aplicado a estimación, eso significa que la herramienta debe proteger una conversación útil, no sustituirla por un ritual.
Por eso los votos privados son valiosos: evitan que una primera opinión arrastre al resto del equipo. Pero el voto privado no basta si cada persona llega con una escala distinta. Primero hay que alinear la comparación; después votar sin influencia mutua; finalmente conversar las diferencias relevantes.
En una herramienta como Stimo, esto puede aterrizarse de forma simple: preparar la historia con criterios visibles, votar en privado, revelar resultados cuando todos hayan votado y usar una nueva ronda si la conversación cambia el entendimiento. Stimo también permite usar Fibonacci o jornadas, pero la consistencia no nace de la escala elegida; nace de cómo el equipo la interpreta.
4. Decide qué hacer cuando los votos no coinciden
La dispersión no es un fallo. A menudo es la parte más valiosa de la estimación. Lo importante es saber leerla sin convertirla en una defensa de posiciones.
Cuando aparecen votos separados, evita preguntar “¿por qué has puesto tanto?” o “¿por qué tan poco?”. Esas preguntas suenan a juicio. Mejor usa preguntas comparativas:
- ¿Qué viste que la historia ancla no tenía?
- ¿Qué supuesto estás haciendo sobre el alcance?
- ¿Qué dependencia te preocupa?
- ¿Qué parte consideras ya resuelta?
- ¿Qué tendría que cambiar para que la vieras como una historia menor?
Después de escuchar, el equipo tiene tres opciones prácticas:
- Mantener la historia y volver a votar si el desacuerdo era de interpretación.
- Ajustar criterios o alcance si se descubrió una ambigüedad relevante.
- Dividir o posponer si la incertidumbre domina la conversación.
La consistencia no significa que todos voten igual a la primera. Significa que, al revelar diferencias, el equipo sabe convertirlas en decisiones.
Un criterio útil: si la conversación aporta contexto nuevo, merece una nueva ronda. Si la conversación solo repite preferencias personales, conviene cerrar con la mejor decisión disponible y revisar la escala más adelante.
Errores comunes que vuelven inestable la escala
Hay patrones que dañan la consistencia de los story points aunque el equipo use planning poker correctamente.
1. Cambiar el significado de los puntos según la persona.
Si “3 puntos” significa una cosa para backend y otra para QA, la escala deja de ser compartida. Es mejor hablar de trabajo total y riesgos visibles, no de esfuerzo individual aislado.
2. Usar historias antiguas sin revisar contexto.
Una historia de hace meses puede no ser buena referencia si el producto, el equipo o la arquitectura cambiaron. Las anclas deben revisarse, no venerarse.
3. Convertir la estimación en compromiso cerrado.
Los story points ayudan a planificar, pero no eliminan la incertidumbre. Si se usan como promesa rígida, el equipo tenderá a inflar o defender números.
4. Discutir diferencias pequeñas con demasiada energía.
No todas las discrepancias merecen diez minutos. Si la decisión de planificación no cambia, quizá basta con acordar la cifra y seguir.
5. Estimar historias que todavía no tienen una pregunta clara.
Si nadie sabe qué decisión se necesita, votar solo produce ruido. Antes de estimar, aclara si el problema es alcance, riesgo, dependencia o prioridad.
Conclusión: una escala consistente es un acuerdo vivo
Los story points no son una fórmula matemática. Son un lenguaje compartido para comparar trabajo bajo incertidumbre. Cuando ese lenguaje no está calibrado, el equipo discute números. Cuando sí lo está, discute supuestos, riesgos y decisiones.
La práctica más sencilla para mejorar la consistencia es esta: elige pocas historias ancla, escribe por qué representan ese tamaño y compáralas antes de votar cada historia nueva. Después usa el planning poker para revelar diferencias, no para forzar unanimidad.
Si el equipo sale del refinamiento con una estimación y una razón entendida por todos, la sesión ya hizo su trabajo.
Fuentes consultadas
¿Listo para ponerlo en práctica?
Crear una sala en Stimo