Calibra tus story points antes de votar: una rutina para refinamientos más cortos
En muchos refinamientos, el problema no es que el equipo no sepa estimar. El problema es que cada persona llega con una escala distinta en la cabeza.
Publicado el
En muchos refinamientos, el problema no es que el equipo no sepa estimar. El problema es que cada persona llega con una escala distinta en la cabeza.
Para una historia parecida, alguien piensa en un cambio pequeño de interfaz, otra persona incluye pruebas de regresión, otra recuerda una dependencia de datos y alguien más compara con una historia antigua que salió mal. Después aparece la ronda de planning poker y la conversación se convierte en una negociación: “¿5 u 8?”, “¿seguro que no es 3?”, “si lo hacemos rápido, quizá…”.
Los story points no nacieron para traducir trabajo a horas con otra etiqueta. Su valor está en la estimación relativa: comparar una historia con otras ya conocidas y usar esa comparación para conversar sobre esfuerzo, complejidad, incertidumbre y riesgo. Atlassian lo explica en su guía sobre story points y estimación ágil: la práctica funciona mejor cuando el equipo estima por comparación y calibra su escala.
La tesis práctica es sencilla: antes de votar, dedica unos minutos a construir una referencia común. No para acertar el número perfecto, sino para que el número signifique algo parecido para todo el equipo.
El problema no es el voto: es la escala invisible
Una ronda de planning poker parece objetiva porque todas las personas usan las mismas cartas. Pero eso no garantiza que estén usando el mismo criterio.
Ejemplo hipotético: el equipo estima “permitir al usuario cambiar su email”. Para una persona, la historia incluye un campo, validación y guardado. Para otra, incluye confirmación por correo, invalidación de sesiones, permisos, auditoría y casos de soporte. Si ambas votan sin calibrar, la diferencia aparecerá como desacuerdo numérico, cuando en realidad es una diferencia de alcance.
Ahí es donde los story points pueden ayudar o confundir. Ayudan cuando expresan una comparación compartida: “esto se parece más a aquella historia de 5 que a aquella de 2”. Confunden cuando cada persona usa su propia memoria, su propia tolerancia al riesgo o su propia idea de “pequeño”.
El Agile Manifesto no habla de story points, pero sí ofrece una brújula útil: valorar individuos e interacciones y responder al cambio por encima de procesos rígidos. Aplicado a la estimación, esto implica que la herramienta y la escala deben servir a la conversación, no reemplazarla.
Una rutina de calibración en 7 minutos
La calibración no necesita convertirse en una ceremonia adicional. Puede ser una secuencia breve al inicio del refinamiento o antes de votar una historia con incertidumbre.
Prueba esta rutina:
- Elige dos historias de referencia. Una pequeña y bien entendida; otra de tamaño medio con algo de complejidad. Mejor si el equipo las recuerda y fueron completadas recientemente.
- Ponles nombre, no solo número. Por ejemplo: “2 puntos = cambio de texto con traducciones y prueba básica”; “5 puntos = nuevo flujo simple con validaciones y coordinación con backend”.
- Aclara qué dimensión pesa más. ¿Estamos comparando volumen de trabajo, complejidad técnica, incertidumbre, dependencias o riesgo de pruebas? Los story points suelen combinar varias dimensiones, pero conviene explicitar cuál domina en esa historia.
- Pide estimar por comparación. Antes de votar, cada persona debería poder responder: “¿esta historia se parece más a la referencia A o a la B, y por qué?”.
- Vota en privado. La votación privada evita que el primer número arrastre al resto del equipo.
- Revela y conversa extremos. No empieces por el promedio. Empieza por los supuestos de quien votó más bajo y más alto.
- Decide la siguiente acción. Cerrar estimación, aclarar alcance, dividir la historia o hacer otra ronda solo si cambió el entendimiento.
La clave está en separar dos momentos: primero calibrar criterio; después votar. Si se mezclan, la conversación tiende a defender números en lugar de contrastar supuestos.
Marco de decisión: cerrar, aclarar, dividir o repetir
Después de revelar votos, no todas las diferencias requieren la misma respuesta. Usa este marco sencillo para decidir qué hacer:
| Señal observada | Qué puede indicar | Acción recomendada |
|---|---|---|
| Votos cercanos y razones parecidas | Escala compartida suficiente | Cerrar con el criterio acordado |
| Votos cercanos pero razones distintas | Consenso superficial | Preguntar qué incluye cada voto antes de cerrar |
| Un voto alto por dependencia concreta | Riesgo no incorporado por todos | Aclarar dependencia o añadir tarea visible |
| Votos muy separados por alcance distinto | Historias diferentes en la cabeza | Reescribir alcance o dividir |
| Segunda ronda igual de dispersa | La conversación no cambió el entendimiento | No forzar número; pedir más contexto |
Este marco evita dos errores frecuentes: convertir la mediana en una respuesta automática o repetir rondas hasta que el equipo se canse. La mediana puede ser útil para ubicar el centro de la ronda, pero no explica por sí sola por qué existe distancia entre votos. La decisión útil sale de conectar el número con el supuesto.
Plantilla rápida para calibrar una historia
Puedes usar esta plantilla antes de votar historias que generen dudas:
Historia a estimar:
Como usuario, quiero cambiar mi email para mantener actualizada mi cuenta.
Referencia baja:
“Cambio simple de texto con traducciones y prueba básica” = 2 puntos.
Referencia media:
“Nuevo flujo con validación, persistencia y coordinación entre frontend/backend” = 5 puntos.
Pregunta de calibración:
¿Esta historia se parece más a la referencia baja o media? ¿Qué la acerca o la aleja?
Supuestos explícitos antes de votar:
- Incluye validación de formato.
- Incluye confirmación por correo.
- No incluye recuperación de cuenta.
- Falta confirmar si hay auditoría obligatoria.
Regla de decisión:
Si la diferencia principal es la auditoría, no discutimos puntos: aclaramos ese dato. Si el alcance queda confirmado, votamos de nuevo.
Esta plantilla no intenta eliminar la incertidumbre. La hace visible antes de que la incertidumbre se esconda dentro de una carta.
Ejemplo aplicado: cuando un 3 y un 8 no discuten lo mismo
Imagina un equipo que estima esta historia: “Como cliente, quiero descargar mis facturas en PDF desde mi perfil”.
Antes de votar, el Scrum Master propone dos referencias:
- 3 puntos: añadir una descarga ya generada a una pantalla existente.
- 8 puntos: generar un documento nuevo con datos de varias fuentes y reglas de permisos.
El Product Owner aclara que el PDF debe estar disponible en el perfil, pero todavía no sabe si se genera bajo demanda o si ya existe en el sistema de facturación. El equipo decide votar igualmente para detectar supuestos.
Resultado hipotético: frontend vota 3, backend vota 8, QA vota 5, UX vota 3.
Sin calibración, la conversación podría ir hacia “¿lo dejamos en 5?”. Con calibración, la pregunta cambia: “¿qué versión estamos estimando?”. Backend votó 8 porque asumió generación bajo demanda y conexión con facturación. Frontend votó 3 porque asumió un enlace a un PDF existente. QA votó 5 porque anticipó permisos y pruebas con diferentes tipos de cliente.
La decisión no es promediar. La decisión útil es pedir una aclaración: ¿el PDF existe o hay que generarlo? Si existe, probablemente la historia se acerca a la referencia de 3 o 5. Si no existe, quizá hay que dividir: una historia para generación y otra para exposición en perfil.
El equipo no ha “perdido tiempo” calibrando. Ha evitado cerrar una estimación basada en tres historias distintas.
Errores comunes al usar story points
1. Convertir puntos en horas encubiertas.
Si cada punto equivale mentalmente a media jornada, el equipo pierde la comparación relativa y vuelve a la precisión falsa.
2. Cambiar la escala en cada refinamiento.
Si un 5 significa una cosa cada semana, la estimación deja de servir como lenguaje compartido.
3. Buscar consenso rápido antes de entender la diferencia.
Un número aceptado por cansancio no mejora la planificación. Solo desplaza la duda al Sprint.
4. Usar otra ronda sin cambiar contexto.
Repetir la votación puede ser útil si la conversación aclaró algo. Si no cambió ningún supuesto, la segunda ronda solo mide presión social.
5. Dejar que roles no estimadores arrastren el número.
El Product Owner y el Scrum Master aportan contexto y facilitación, pero conviene cuidar que no condicionen la estimación técnica. En herramientas como Stimo, la ayuda documenta un flujo con votación privada, revelado de resultados y lectura de mediana/media por perfil; usado con criterio, puede apoyar la conversación sin sustituirla.
Conclusión práctica
Si tus story points generan debates largos, no empieces intentando afinar la cifra. Empieza calibrando la escala.
El próximo refinamiento, prueba esta regla: antes de votar una historia dudosa, nombra dos historias de referencia y pide a cada persona que compare contra ellas. Después votad en privado, revelad y conversad solo los supuestos que expliquen la distancia.
La estimación no mejora porque el equipo discuta más. Mejora cuando discute lo correcto: alcance, riesgo, dependencias y entendimiento compartido. El número viene después.
Fuentes consultadas
¿Listo para ponerlo en práctica?
Crear una sala en Stimo