¿Qué son los story points? Una guía práctica

Un story point (punto de historia) es una unidad de esfuerzo relativo que un equipo asigna a un trabajo, combinando qué tan complejo es, qué tan incierto es, y cuánto hay de él, en lugar de cuántas horas tomará. Los equipos comparan cada ítem con otros ("esto es más o menos el doble de trabajo que aquello") en vez de predecir un tiempo de reloj. Los puntos se eligen casi siempre con una escala como Fibonacci durante una sesión de planning poker. A continuación: qué miden realmente, qué dice la evidencia, y cómo usarlos sin prometer de más.

¿Qué es un story point?

Un story point responde a una pregunta comparativa, no absoluta. En vez de "cuántas horas tomará esto", el equipo pregunta "qué tan grande es esto comparado con un trabajo que ya conocemos". Una historia en la que todos coinciden que es pequeña puede ser un 2, algo más sustancioso un 5, algo grande y difuso un 13. El número no tiene un tiempo fijo asociado. Es un tamaño relativo y compartido.

El sentido de usar una unidad abstracta es separar la estimación de la velocidad de cualquier persona en particular y de la presión de comprometerse con una fecha límite. Un desarrollador junior y uno senior pueden tardar cantidades de tiempo distintas, pero a menudo pueden coincidir en que un ítem es aproximadamente el doble que otro.

De qué está hecho un story point

Tres cosas se combinan en un solo número:

• Complejidad: qué tan intrincado es el trabajo, cuántas partes móviles tiene, cuántos sistemas afecta.
• Incertidumbre: cuánto no sabe todavía el equipo. Las incógnitas y el riesgo empujan el número hacia arriba.
• Volumen: cuánto trabajo repetitivo hay, incluso cuando cada parte es sencilla.

Por eso dos ítems que tomarían horas similares pueden recibir puntos diferentes. Un cambio simple repartido en cuarenta archivos y un algoritmo complicado en un solo archivo son ambos "grandes", por razones distintas.

Por qué los equipos estiman en puntos en vez de horas

La estimación relativa es popular por razones que tienen más que ver con las personas que con las matemáticas:

• Desacopla la estimación del individuo. Las horas dependen de quién hace el trabajo. El tamaño relativo está pensado para ser más estable entre personas.
• Comparar es más rápido que predecir. Juzgar que un ítem es más grande que otro es más rápido que pronosticar una duración exacta, así que las sesiones avanzan más rápido.
• Resiste la falsa precisión. "13 puntos" señala la incertidumbre con honestidad. "16,5 horas" finge una precisión que nadie tiene.
• Impulsa la conversación. El verdadero resultado de estimar en equipo no es el número. Es la discusión que saca a la luz el trabajo oculto, como en una sesión de planning poker.

Esos son beneficios reales. Pero vale la pena ser honestos sobre la parte que la mayoría de las guías se saltan.

Qué dice realmente la investigación

La afirmación común de que los story points son más precisos que las estimaciones en horas no está bien respaldada por estudios controlados.

En un conjunto de experimentos controlados, desarrolladores profesionales estimaron las mismas tareas de dos formas: unos daban story points, otros daban horas de trabajo. Las estimaciones en story points resultaron menos precisas que las estimaciones en horas, y tomaron más tiempo en producirse, incluso entre desarrolladores con bastante experiencia en story points. El mismo trabajo encontró que el "tamaño" en puntos de una tarea variaba mucho según quién estimara, justo lo contrario de la propiedad de independencia respecto a la persona que se supone que tienen los puntos.

El patrón se mantiene a gran escala. En un análisis de 2022 con 37.440 historias de usuario reales en 37 proyectos de código abierto, los investigadores compararon los story points de cada equipo con cuánto tiempo tomó realmente el trabajo. Los puntos se alinearon bien con el esfuerzo real en solo cerca del 7% de los proyectos. En el resto, la relación fue media o débil, y la estimación humana original estuvo equivocada, demasiado alta o demasiado baja, en aproximadamente tres de cada cuatro historias. Revisiones más amplias de la estimación ágil llegan a una versión más moderada del mismo punto: los story points son la forma más común en que los equipos dimensionan el trabajo, pero no hay evidencia sólida de que predigan el esfuerzo con precisión. (Referencias completas en Fuentes, más abajo.)

La conclusión honesta: los story points no son una forma confiable de predecir cuánto tiempo tomará un solo ítem. Si los adoptas esperando pronósticos precisos por ítem, te decepcionarás, y la investigación explica por qué.

Entonces, ¿para qué sirven los story points?

Para bastante, siempre que los uses para el trabajo correcto.

• Entendimiento compartido. Cuando los votos divergen, la discusión revela supuestos, tareas faltantes y riesgo. Ese alineamiento es la verdadera entrega, y es por eso que la técnica vale el tiempo.
• Pronóstico aproximado a lo largo de muchos ítems. Las estimaciones individuales son ruidosas, pero en un backlog completo los errores se cancelan parcialmente. Rastrear cuántos puntos completa un equipo por sprint (su velocidad) da un pronóstico utilizable y aproximado, mucho mejor que sumar horas adivinadas.
• Señalar los ítems preocupantes. Un 13 o un 21 es una señal: esto es demasiado grande o demasiado desconocido. Divídelo antes de que duela.
• Mantener la estimación humana. El dimensionamiento relativo evita la presión de los plazos y la culpa individual que provocan las estimaciones en horas.

Nota que nada de esto requiere que los puntos equivalgan al esfuerzo con precisión. Requiere un equipo que converse y compare de forma consistente.

Cómo estimar en story points

1. Elige una escala. La mayoría de los equipos usa un mazo Fibonacci (0, 1, 2, 3, 5, 8, 13, 21). Las brechas crecientes reflejan la incertidumbre creciente, así que no te piden distinguir detalles mínimos entre ítems grandes.
2. Elige una historia de referencia. Acuerden un ítem bien comprendido como ancla ("este es nuestro 3"). Estimen todo lo demás por comparación con él.
3. Estimen juntos, revelen juntos. Usen planning poker para que nadie se ancle en el primer número dicho en voz alta. El método completo está en nuestra guía paso a paso.
4. Reestimen cuando sepan más. Los puntos son una foto del entendimiento actual, no un contrato. Actualícenlos cuando cambie el panorama.

Story points vs. horas

Ninguno de los dos es magia. Si un stakeholder realmente necesita una fecha, los puntos por sí solos no la darán. Las tendencias de velocidad más una conversación se acercarán más que un montón de horas adivinadas.

Errores y usos indebidos comunes

• Convertir puntos en horas. Una tabla "1 punto = 4 horas" desecha toda la razón de usar puntos y reintroduce la falsa precisión.
• Comparar la velocidad entre equipos. Los puntos se calibran por equipo. El 8 del Equipo A no es el 8 del Equipo B. Usar la velocidad como un ranking de productividad es un antipatrón bien conocido.
• Tratar los puntos como una métrica de desempeño. En el momento en que los puntos se convierten en un objetivo, se inflan y dejan de significar algo (la ley de Goodhart en la práctica).
• Esperar precisión por ítem. Como muestra la investigación, los puntos de un solo ítem son un predictor débil de su tiempo real. Pronostica a lo largo de muchos ítems, no de uno.
• No reestimar nunca. Los puntos fijados antes de entender el trabajo no son sagrados. Actualízalos.

Preguntas frecuentes

¿Los story points son lo mismo que las horas?

No. Las horas son una duración absoluta ligada a una persona específica. Los story points son un tamaño relativo que combina complejidad, incertidumbre y volumen, y están pensados para ser independientes de quién hace el trabajo.

¿Cuántas horas equivale un story point?

No hay una conversión fija, y crear una anula el propósito. Algunos equipos observan de manera informal que un punto tiende a tomar cierto rango de tiempo para ellos, pero eso es un patrón detectado después del hecho, no una regla para estimar.

¿Qué escala deberíamos usar para los story points?

Fibonacci (0, 1, 2, 3, 5, 8, 13, 21) es la más común porque las brechas crecientes reflejan la incertidumbre creciente en los ítems más grandes. La estimación por tallas de camiseta funciona bien para un dimensionamiento rápido y aproximado.

¿Son realmente precisos los story points?

Para predecir el esfuerzo de un solo ítem, la evidencia es débil: los estudios controlados no han mostrado una ventaja de precisión clara sobre las horas, y un análisis a gran escala encontró que los puntos se correlacionan con el esfuerzo real de forma inconsistente. Su valor está en el entendimiento compartido y el pronóstico aproximado a lo largo de muchos ítems, no en la predicción precisa por ítem.

¿Se puede comparar la velocidad entre equipos?

No. Los puntos se calibran dentro de cada equipo, así que la velocidad de un equipo no es comparable con la de otro. Usar la velocidad para clasificar equipos fomenta la inflación de puntos y es un antipatrón común.

¿Quién asigna los story points?

Las personas que harán el trabajo, en conjunto, generalmente en una sesión de planning poker. El Product Owner aclara el alcance pero no fija el número, y el Scrum Master facilita.

¿Los story points miden el esfuerzo o la complejidad?

Ambos, más la incertidumbre y el volumen. Combinan varios factores en un solo número relativo, por eso dos ítems con un esfuerzo bruto similar pueden recibir puntos diferentes.

Fuentes

1. Usman, M., Mendes, E., Weidt, F. & Britto, R. (2014). Effort estimation in agile software development: a systematic literature review. PROMISE 2014.
2. Jørgensen, M. & Escott, E. Relative estimates of software development effort: are they more accurate or less time-consuming to produce than absolute estimates? (experimentos controlados con desarrolladores profesionales).
3. Tawosi, V., Moussa, R. & Sarro, F. (2022). On the Relationship Between Story Points and Development Effort in Agile Open-Source Software. ESEM 2022 (37.440 historias de usuario, 37 proyectos).
4. Pasuksmit, J., Thongtanunam, P. & Karunasekera, S. (2022). Story points changes in agile iterative development. Empirical Software Engineering.