Hoja de referencia de story points
Una referencia densa de una sola página para un equipo que ya conoce la teoría y solo quiere los números, la escala y los modos de fallo comunes en un solo lugar. Para la explicación completa detrás de cualquier punto de esto, consulta la guía completa de story points.
La escala
| Puntos | Significado | Ejemplo típico |
|---|---|---|
| 0 | Trivial, apenas vale la pena registrarlo | Corregir un error de tipeo, ajustar un valor de configuración |
| 1 | Diminuto, totalmente entendido | Añadir una regla de validación |
| 2 | Pequeño, camino claro | Un campo CRUD directo |
| 3 | Sólido, sigue siendo claro | Un formulario nuevo con algunos estados |
| 5 | Tamaño o complejidad considerable | Una nueva integración de API con documentación conocida |
| 8 | Grande - vale la pena vigilarla | Toca varios sistemas, incógnitas reales |
| 13 | Cerca del límite | Normalmente debería dividirse antes de un sprint |
| ? | Aún no se puede estimar | Hazla un spike o divídela |
Justificación completa de por qué los saltos se ensanchan: Fibonacci en story points explicado.
Ejemplos de referencia base por tamaño
Los anclajes concretos ayudan más que la tabla abstracta anterior. Adapta estos a tu propio código, pero el patrón se generaliza:
- 1-2: un cambio de configuración, una actualización de texto, una sola regla de validación nueva, una corrección de bug directa con causa conocida.
- 3: un campo de formulario nuevo con validación básica, un endpoint de API nuevo y pequeño con un patrón existente a seguir, un componente de UI bien acotado.
- 5: una página o flujo nuevo con un par de estados, una integración con una API de terceros bien documentada, una refactorización moderada confinada a un solo módulo.
- 8: una funcionalidad que abarca varias pantallas o servicios, una integración con una API poco familiar o mal documentada, un cambio que toca infraestructura compartida.
- 13: raro en un sprint sano - normalmente una señal de que la historia debería haberse dividido durante el refinamiento.
Las reglas, en resumen
- Vota en privado, revela al mismo tiempo. Nunca digas una opinión antes de votar: ancla la sala.
- Dispersión amplia → los votantes más alto y más bajo explican primero, luego se vota de nuevo una vez.
- ¿Sigue dividido después de dos rondas? La historia no está lista. Apárcala, no la promedies.
- Los puntos miden el esfuerzo relativo, no las horas. No existe una tasa de conversión por historia: ver por qué no.
- Los puntos están calibrados según la historia propia de un equipo. Nunca compares valores de puntos entre equipos.
- El Product Owner aclara el alcance; no vota.
Mecánica completa: la guía de Scrum Poker.
Antipatrones de conversión (no hagas esto)
- "1 punto = 4 horas". Cualquier tasa horaria fija reintroduce la falsa precisión que los puntos existen para eliminar.
- Comparar un "5" del Equipo A con un "5" del Equipo B. Equipos distintos, calibración distinta, un número que se ve igual: comparación sin sentido.
- Volver a estimar una historia en curso solo porque está tardando más. El alcance no ha cambiado, así que la estimación tampoco debería: ver cuándo volver a estimar a mitad de sprint.
- Tratar la estimación como una promesa de entrega. Las estimaciones son pronósticos, no compromisos; confundirlas causa relleno y votación deshonesta.
- Estimar una historia sin criterios de aceptación. Produce una dispersión amplia que parece desacuerdo pero en realidad es que todos están estimando una historia imaginaria diferente.
Quién vota: en resumen
| Rol | ¿Vota? |
|---|---|
| Desarrolladores, QA, cualquiera que construya o verifique el trabajo | Sí |
| Product Owner | No - aclara el alcance, no vota |
| Interesados no técnicos | No - solo responde preguntas |
| Diseñadores | Depende - primero hay que acordar la dimensión que se está estimando |
| Espectadores | No - observan sin afectar la ronda |
Etiqueta completa por rol: quién debería estar en la sala.
Hoja de referencia por tamaño de equipo
- 2-3 personas: convergencia rápida, pero cuidado con los puntos ciegos compartidos; compensa con revisiones de calibración más frecuentes.
- 4-7 personas: el punto óptimo generalmente citado para un desacuerdo real sin caos.
- 8+ personas: las voces junior empiezan a anclarse a las senior incluso antes de que ocurra la revelación. Impón la revelación simultánea con rigor, y trata los votos atípicos como una señal valiosa para proteger contra el pensamiento de grupo.
Guía completa: cómo el tamaño del equipo afecta la precisión de la estimación.
Referencia rápida: matemática de la velocidad
Velocidad promedio = suma de puntos completados en los últimos 3-4 sprints ÷ número de sprints.
Pronóstico aproximado = puntos restantes en el backlog ÷ velocidad promedio = sprints necesarios. Exprésalo siempre como un rango (la velocidad varía aproximadamente ±25% de sprint a sprint), nunca como un número decimal único. El conversor de story points a horas hace esta matemática y te da el rango automáticamente.
Capacidad para un sprint específico = (tamaño del equipo × días laborables − días de ausencia planificados) × factor de enfoque (normalmente 70-80%). La calculadora de capacidad de sprint hace esto por ti.
¿Necesitas un número inicial rápido?
La calculadora de story points convierte tres calificaciones rápidas (complejidad, volumen, incertidumbre) en una carta de partida sugerida, con orientación honesta para cuando la respuesta correcta es "hazlo un spike" en lugar de un número. Úsala antes de una sesión para formar tu propia opinión, y luego llévala al voto del equipo.