Volver al blog

Estimación más fiable con story points: calibra antes de discutir

En muchos refinamientos, la discusión empieza demasiado pronto. Una persona dice 3 puntos, otra dice 8, alguien pregunta si eso incluye pruebas, aparece una dependencia no mencionada y el equipo termina negociando el

Publicado el

Estimación más fiable con story points: calibra antes de discutir

En muchos refinamientos, la discusión empieza demasiado pronto. Una persona dice 3 puntos, otra dice 8, alguien pregunta si eso incluye pruebas, aparece una dependencia no mencionada y el equipo termina negociando el número antes de compartir el criterio.

El problema no son los story points. El problema suele ser que cada persona está comparando contra una referencia distinta. Para una, 5 puntos significa una historia pequeña con algo de incertidumbre. Para otra, significa varios días de trabajo con coordinación entre perfiles. Si el equipo no calibra antes, la votación se convierte en una mezcla de intuiciones incompatibles.

Los story points funcionan mejor cuando se usan como estimación relativa: no intentan medir horas exactas, sino comparar tamaño, complejidad, riesgo e incertidumbre entre elementos. Atlassian presenta esta idea junto con prácticas como planning poker y calibración para que el equipo llegue a una comprensión compartida antes de comprometerse.

Esta guía propone un cambio sencillo: antes de discutir cada historia, calibra una referencia común. No para eliminar la conversación, sino para hacerla más útil.

Por qué calibrar antes de votar reduce discusiones largas

Cuando un equipo estima sin referencia compartida, cada número abre una conversación distinta. Un 8 puede significar mucho trabajo, riesgo técnico, dependencias externas, ambigüedad de alcance o simplemente falta de familiaridad. Si nadie pregunta por qué, el equipo solo ve dispersión. Si pregunta demasiado tarde, ya está defendiendo posiciones.

La calibración cambia el orden de la conversación. Primero se acuerda una escala práctica basada en historias conocidas. Después se compara la historia actual contra esas referencias. Así, la pregunta deja de ser qué número te parece y pasa a ser a qué se parece más esta historia y qué la hace distinta.

Esto encaja con el valor ágil de priorizar individuos e interacciones sobre procesos y herramientas. La escala no sustituye el juicio del equipo; lo hace visible. El objetivo no es producir una cifra perfecta, sino revelar diferencias de criterio antes de que se conviertan en compromisos poco fiables.

Una buena calibración ayuda a distinguir tres tipos de desacuerdo:

  • Diferencia de información: alguien conoce un riesgo que el resto no ha considerado.
  • Diferencia de alcance: no todos están imaginando el mismo resultado.
  • Diferencia de criterio: el equipo no aplica igual la escala de puntos.

Los tres son valiosos. Pero solo se pueden resolver si aparecen antes de cerrar la estimación.

Construye una escala de referencia con historias ancla

La calibración empieza eligiendo historias ancla: elementos anteriores o conocidos que el equipo pueda usar como comparación. No tienen que ser ejemplos perfectos. Tienen que ser suficientemente claros para que el equipo recuerde qué implicaron.

Puedes preparar una escala simple antes del refinamiento:

  • 1 punto: cambio mínimo, bajo riesgo, sin coordinación relevante.
  • 2 puntos: trabajo pequeño, entendido, con validación sencilla.
  • 3 puntos: historia habitual, con algo de integración o pruebas.
  • 5 puntos: varios perfiles implicados, algunas incógnitas o dependencias.
  • 8 puntos: historia grande o incierta, probablemente candidata a dividir.

La escala no debe ser una tabla rígida. Debe ser una conversación breve sobre referencias. Por ejemplo: esta historia de edición de perfil fue un 3 porque afectaba a interfaz, validación y pruebas básicas. Aquella integración fue un 5 porque requería coordinación con otro sistema y validación adicional.

El equipo puede usar una secuencia tipo Fibonacci si ya le funciona. Lo importante no es la numeración exacta, sino que los saltos entre valores reflejen incertidumbre creciente. Si una historia parece estar entre 5 y 8, la conversación útil no es promediar. La conversación útil es entender qué la empuja hacia 8 y si se puede reducir esa incertidumbre.

Criterios para elegir buenas historias ancla:

  1. Que el equipo las conozca o pueda entenderlas rápido.
  2. Que representen tamaños distintos, no solo historias pequeñas.
  3. Que incluyan algún ejemplo con riesgo o dependencia.
  4. Que no generen una discusión nueva sobre si se estimaron bien en el pasado.
  5. Que puedan revisarse cuando el equipo aprenda más.

Si el equipo es nuevo o no tiene histórico, usa ejemplos hipotéticos acordados en la sesión. No serán tan fuertes como el aprendizaje real, pero ayudan a empezar con un lenguaje común.

Un flujo de refinamiento para estimar con menos fricción

La calibración no necesita convertir el refinamiento en una ceremonia pesada. Basta con introducir un pequeño paso antes de votar y otro después de revelar resultados.

Un flujo práctico puede ser este:

  1. Presenta la historia en términos de resultado esperado. Antes de hablar de puntos, confirma qué necesidad se quiere cubrir y qué quedará fuera.

  2. Haz visibles los criterios de aceptación. Si los criterios no están claros, la estimación será una opinión sobre una idea incompleta.

  3. Compara contra una historia ancla. Pregunta: se parece más a nuestro 3, a nuestro 5 o a nuestro 8. Esta pregunta baja la abstracción.

  4. Identifica variables de esfuerzo. Pide al equipo que nombre factores como desarrollo, pruebas, UX, integración, datos, dependencias, riesgo o incertidumbre.

  5. Vota en privado. La votación privada reduce el arrastre hacia la primera opinión fuerte. En planning poker, cada persona estima antes de ver el voto del resto.

  6. Revela y conversa solo la dispersión relevante. Si todos están cerca, no alargues la conversación. Si hay distancia, escucha primero los extremos: qué vio la persona que votó bajo y qué vio la persona que votó alto.

  7. Decide la siguiente acción. No todo desacuerdo se resuelve con más conversación. A veces hay que dividir la historia, aclarar un criterio, investigar una dependencia o aceptar una estimación más conservadora.

En herramientas como Stimo, este flujo puede apoyarse con salas compartidas, votación privada, revelado por el organizador y revisión de resultados como mediana y media. Eso no sustituye la conversación, pero ayuda a separar dos momentos: primero pensar individualmente, después comparar criterios.

Una regla útil: si el equipo discute más el número que el alcance, vuelve a la historia ancla. Si discute más el alcance que el número, probablemente la historia aún no está lista para estimarse.

Cómo interpretar la dispersión sin negociar puntos

Después de revelar votos, la tentación habitual es buscar un punto medio rápido. Pero una media no explica el desacuerdo. Solo lo resume.

Si aparecen votos 3, 5 y 8, evita empezar con alguien acepta 5. Mejor pregunta:

  • Quienes votaron 3, ¿qué asumieron que ya estaba resuelto?
  • Quienes votaron 8, ¿qué riesgo o trabajo adicional están viendo?
  • ¿Estamos estimando el mismo alcance?
  • ¿Hay dependencias que no aparecen en la historia?
  • ¿La historia incluye pruebas, diseño, datos o despliegue que alguien no contempló?

El objetivo es convertir la dispersión en aprendizaje. A veces el voto alto revela una dependencia real. A veces el voto bajo muestra que la historia puede partirse. A veces todos entienden lo mismo, pero aplican la escala de forma distinta. En ese caso, vuelve a las historias ancla y ajusta la referencia.

También conviene separar estimación de compromiso. Un equipo puede estimar una historia en 8 y decidir no llevarla al Sprint hasta dividirla. O puede estimarla en 5 y marcar una duda específica para resolver antes de empezar. La estimación es una ayuda para decidir, no una promesa exacta.

Errores comunes al usar story points

El primer error es traducir puntos a horas de forma automática. Si cada punto acaba significando media jornada o un día, la conversación vuelve a una falsa precisión. Los story points pierden valor cuando dejan de comparar complejidad e incertidumbre.

El segundo error es usar la escala como arma de presión. Si el Product Owner o una persona con más autoridad empuja hacia abajo la estimación, el equipo aprende a votar lo que se espera, no lo que ve. Por eso la votación privada es útil: protege el criterio inicial antes de la conversación.

El tercer error es discutir todas las diferencias con la misma intensidad. No toda variación merece diez minutos. Si los votos están próximos y no hay dudas nuevas, decide y avanza. Reserva la conversación profunda para dispersión amplia o riesgos no compartidos.

El cuarto error es no revisar las referencias. Una escala de puntos no debería quedar congelada durante meses si el equipo, el producto o la arquitectura cambian. Revisa historias ancla cuando notes estimaciones inconsistentes o discusiones repetidas.

El quinto error es estimar historias demasiado grandes. Si una historia acumula demasiadas incógnitas, la estimación será ruidosa aunque el equipo calibre bien. En ese caso, la mejor decisión puede ser dividir, investigar o reformular.

Conclusión: calibra para conversar mejor, no para acertar siempre

La estimación ágil no busca adivinar el futuro con exactitud. Busca que el equipo comparta criterio, haga visibles los riesgos y tome mejores decisiones sobre qué puede abordar.

Calibrar antes de discutir ayuda porque crea una referencia común. Las historias ancla reducen interpretaciones ocultas. La votación privada evita sesgos iniciales. El revelado ordenado convierte la dispersión en conversación útil. Y la revisión de mediana, media o resultados por perfil puede aportar señales, siempre que el equipo no olvide que la decisión final depende del contexto.

Para tu próximo refinamiento, prueba un experimento pequeño: elige tres historias ancla, preséntalas al inicio y pide que cada nueva historia se compare contra ellas antes de votar. Si la discusión se vuelve más concreta, la calibración ya está cumpliendo su función.

Fuentes consultadas

¿Listo para ponerlo en práctica?

Crear una sala en Stimo