Story points: qué son y cómo usarlos en tu equipo

Un story point (punto de historia) es una unidad de estimación relativa. Resume en un número el esfuerzo, la complejidad y la incertidumbre de una historia de usuario o tarea, sin traducirlo a horas ni días.

Las horas miden tiempo; los story points miden cuánto trabajo implica algo comparado con otra cosa que el equipo ya conoce.

Por ejemplo, si tu equipo toma como referencia una tarea sencilla y le asigna 1 punto, una tarea moderada puede valer 3 y una compleja puede valer 8. La escala solo tiene sentido dentro del propio equipo: no existe un "punto estándar" que valga lo mismo en dos equipos.

Esto importa porque dos personas pueden hacer la misma tarea en tiempos distintos. Si ambas la evalúan como "compleja", los puntos capturan esa dificultad compartida sin entrar en discusiones de agenda.

De dónde vienen

Los story points nacieron en la Programación Extrema (XP) a fines de los noventa. Los equipos estimaban en "días ideales" y, para evitar que alguien confundiera un día ideal con un día de calendario, pasaron a llamarlos puntos. Ron Jeffries, uno de los creadores de XP, suele contar esa historia. Mike Cohn los popularizó en User Stories Applied (2004) y Agile Estimating and Planning (2005).

Un dato que conviene tener claro: los story points están fuera de la Guía de Scrum. Muchos equipos de Scrum los usan por decisión propia, y cada equipo puede elegir otra forma de estimar.

La escala de Fibonacci y por qué se usa

Es habitual estimar con los valores de la sucesión de Fibonacci: 1, 2, 3, 5, 8, 13, 21. Otra variante muy usada, la de los mazos de planning poker que difundió Cohn, redondea los valores altos: 1, 2, 3, 5, 8, 13, 20, 40, 100.

La lógica es sencilla: a mayor tamaño, mayor incertidumbre, y la escala se abre. Es fácil distinguir entre una tarea de 2 puntos y una de 3; distinguir entre una de 11 y una de 12 es una precisión falsa. Como no hay valores intermedios, el equipo tiene que elegir y conversar.

Cuando una tarea llega a 13 o 21 puntos, casi siempre conviene dividirla. Una estimación alta es una señal de que el equipo todavía no entiende bien qué implica esa tarea. La estructura de desglose del trabajo sigue la misma idea en proyectos.

Planning poker: cómo se hace y para qué sirve

El planning poker es una técnica de estimación en grupo que describió James Grenning en 2002 y que Cohn difundió después. Toma la idea del método Delphi (estimaciones independientes que se discuten y se repiten) y la lleva a una mesa con cartas. Funciona así:

1. Se presenta una historia de usuario o tarea al grupo y se aclaran dudas.
2. Cada persona elige en silencio la carta con el número que cree que corresponde.
3. Todos muestran sus cartas al mismo tiempo.
4. Si las cartas coinciden o caen en valores vecinos (por ejemplo, 3 y 5), el equipo acuerda uno de la escala. Sacar el promedio da números que no existen en el mazo, como 4.
5. Si hay diferencias grandes, quienes eligieron el valor más alto y el más bajo explican su razonamiento y el equipo vota de nuevo.

El paso clave es mostrar las cartas a la vez. Reduce el anclaje, el sesgo de ajustarse al primer número que se escucha (Tversky y Kahneman lo describieron en 1974), que en una reunión suele venir de la persona con más antigüedad o más confianza.

Como gerente, tu rol en el planning poker es facilitar la conversación y dejar la decisión al equipo. Si participas como estimador, tu número pesa más que el de los demás. Muchos gerentes moderan la sesión sin votar.

Cómo conectan los story points con el sprint

Los story points adquieren sentido dentro de un sprint. Un sprint tiene una duración fija, y la velocidad es la cantidad de puntos que el equipo terminó en cada uno. Solo cuentan las historias que cumplen la definición de hecho; una historia a medias suma cero.

La velocidad sale de la observación de varios sprints y sirve de referencia para los siguientes. Si un equipo terminó 28, 32 y 30 puntos en los últimos tres sprints, su velocidad promedio es 30 (90 / 3), y eso es lo que se planifica en el sprint planning, ajustado por vacaciones o feriados del período. Comprometer 50 puntos porque el gerente quiere acelerar solo produce un sprint backlog inflado y un equipo frustrado.

La tabla siguiente muestra una estimación simple de historias para un sprint. La integración de pagos, que el equipo había estimado en 13, se dividió en dos historias antes de entrar:

Historia	Complejidad percibida	Story points asignados
Configurar acceso de usuario	Baja	2
Integrar pagos: autorización de la tarjeta	Alta	8
Integrar pagos: conciliación diaria	Media	5
Generar reporte mensual	Media	5
Actualizar documentación	Baja	1
Revisar flujo de aprobación	Media	3
Total sprint		24

Si la velocidad del equipo es 25 puntos, este sprint está bien dimensionado. Si la velocidad es 15, hay que mover historias al siguiente ciclo: sacar las dos de pagos (13 puntos) deja 11, y entra una historia más pequeña si hay espacio. Durante el sprint, el burndown chart muestra cuántos de esos 24 puntos quedan pendientes día a día.

Errores comunes al usar story points

Convertir puntos en horas. Cuando un gerente fija que "un punto equivale a cuatro horas", los puntos se vuelven horas con otro nombre y vuelve la discusión de agenda que se quería evitar. Que sean relativos es justamente lo que los hace útiles.

Comparar velocidades entre equipos. Un equipo con 40 puntos por sprint puede estar estimando de forma más generosa que uno con 20. La velocidad solo tiene sentido dentro del mismo equipo a lo largo del tiempo.

Usar la velocidad como meta de desempeño. Si se premia subir la velocidad, las estimaciones se inflan y el número sube sin que el equipo entregue más. Es la ley de Goodhart: una medida que se convierte en objetivo deja de medir bien.

Presionar para bajar estimaciones. Si el equipo dice que algo vale 8 puntos y el gerente insiste en 3, la próxima vez el equipo estimará pensando en lo que el gerente quiere oír. La estimación pierde utilidad y el plan del sprint pierde base real.

Estimar tareas demasiado grandes. Cualquier historia con más de 8 o 13 puntos es candidata a dividirse. Una tarea vaga o enorme no se puede estimar bien ni asignar con claridad.

Lo que ordena todo lo anterior es un acuerdo explícito sobre qué historia de referencia vale 1, cuál vale 3 y cuál vale 8, revisado en la retrospectiva cuando las estimaciones se desvían.

Una alternativa: contar historias terminadas

Algunos equipos dejan de estimar en puntos y cuentan cuántas historias terminan por semana, siempre que las dividan a un tamaño parecido. Es la idea detrás del movimiento #NoEstimates y se apoya en el throughput, una medida que viene de la gestión de flujo. Para un equipo que ya divide bien su trabajo, puede dar pronósticos igual de buenos con menos reuniones de estimación.

Qué gana el gerente que entiende este sistema

Los story points cambian la conversación de "¿cuándo terminas?" a "¿qué tan complejo es esto?". Esa diferencia importa en la gestión diaria.

Cuando el equipo estima con criterios compartidos, el gerente puede planificar con más base, priorizar con menos fricción y detectar antes cuándo un entregable está en riesgo. También puede delegar con más precisión: sabe cuánto puede asumir el equipo en un período sin necesidad de suponer.

El sistema funciona mejor cuando el gerente deja que el equipo sea dueño de las estimaciones. La función gerencial está en el orden de prioridades: qué entra al sprint y qué queda fuera. El esfuerzo de cada tarea lo dice quien la va a hacer. Respetar esa división es lo que separa a los gerentes que aprovechan el sistema de los que lo sabotean sin darse cuenta.