Los story points explicados: estimación relativa en lugar de horas, la escala de Fibonacci, cómo los puntos alimentan la velocidad y las previsiones de release, y cómo estima historias East Agile Tracker.
Un story point es una unidad de tamaño relativo. En lugar de estimar un trabajo en horas o días, el equipo lo compara con trabajo que ya ha hecho: “esto es más o menos el doble de aquello”. El número recoge a la vez el esfuerzo, la complejidad y la incertidumbre.
Por qué relativo y no en horas
Sección titulada «Por qué relativo y no en horas»A las personas se nos da mal predecir cuánto durará una tarea, y bastante bien juzgar si una tarea es más grande que otra. Los story points aprovechan la segunda habilidad.
- Los puntos no dependen de quién haga el trabajo. Una historia vale 3 tanto si la coge una ingeniera sénior como un ingeniero júnior; la diferencia aparece en lo rápido que el equipo termina puntos, no en la estimación.
- Estimar sigue siendo rápido. Comparar una historia con otra conocida lleva segundos. Desglosarla en horas lleva mucho más y rara vez es más preciso.
- Los puntos se convierten en fechas mediante la medición. Una vez que el equipo sabe cuántos puntos termina por iteración —su velocidad—, puede prever cuándo estará terminado un conjunto de historias.
Una estimación es una conversación de dimensionamiento, no una promesa. Si el equipo no se pone de acuerdo en un número, la discusión suele sacar a la luz un malentendido sobre la historia, que es el resultado más útil.
Escalas
Sección titulada «Escalas»Los equipos eligen una escala corta para que las estimaciones sigan siendo aproximadas. Las más comunes:
- Fibonacci — 0, 1, 2, 3, 5, 8, 13. Los saltos crecen con el tamaño, porque las historias grandes son más inciertas.
- Lineal — 0, 1, 2, 3. Una escala pequeña para equipos que dividen el trabajo en piezas finas.
- Tallas de camiseta — S, M, L (a veces XS y XL).
Una historia demasiado grande para el extremo superior de la escala es una señal para dividirla en historias más pequeñas.
Estimar en equipo
Sección titulada «Estimar en equipo»Una técnica habitual es el planning poker: cada persona elige una estimación en privado, todos la muestran a la vez, y quienes dieron la más alta y la más baja explican su razonamiento antes de que el equipo acuerde un número. Mostrarlas a la vez evita que la primera voz condicione al resto.
Se estima antes de iniciar la historia, cuando el equipo entiende qué significa “terminada” para ella: los criterios de aceptación. Consulta Historias de usuario y planificación de iteraciones.
Cómo lo hace East Agile Tracker
Sección titulada «Cómo lo hace East Agile Tracker»- Las features reciben puntos de forma predeterminada. Los bugs y los chores quedan sin estimar salvo que el proyecto active Points for bugs and chores. Consulta Estimar features.
- Incluye tres escalas: Fibonacci (0, 1, 2, 3, 5, 8, 13), East Agile (0, 1, 2, 3) y 3 puntos (1, 2, 3 para Pequeña / Mediana / Grande). La escala se elige por proyecto; cambiarla después no reasigna las estimaciones existentes. Consulta Points.
- Los puntos alimentan la velocidad. Los puntos de una historia cuentan para la velocidad en cuanto alcanza el estado terminado del proyecto, y la velocidad dimensiona las siguientes iteraciones. Consulta Velocidad.
- Las historias sin estimar se pueden buscar. El filtro
is:unestimatedlista las features que aún necesitan un número. Consulta Búsqueda y filtros.
Lecturas adicionales
Sección titulada «Lecturas adicionales»- ¿Qué es la velocidad? — cómo los puntos se convierten en una previsión.
- Scrum frente a Kanban — el lugar de la estimación en cada método.
- eXtreme Programming — el método del que proceden los story points.