Story points: la guía para el founder que paga la cuenta

El equipo dice que rehacer los pagos son 13 puntos. Vos estás tratando de entender si eso vale lo que gastás cada mes. Qué miden realmente los story points, por qué nadie te los convierte en horas y qué mirar en su lugar.

Tres sprints después de arrancar, un founder con el que trabajamos frenó la review e hizo la pregunta que toda la sala venía esquivando. “El equipo dice que rehacer los pagos son 13 puntos. Estoy pagando bastante dinero todos los meses por esto. ¿Qué estoy comprando exactamente?”

Nadie le dio una respuesta limpia. Es lo habitual. También es un fracaso.

Así que, limpio: un story point es una unidad de tamaño relativo, no de tiempo. Junta tres cosas en un solo número: qué tan complejo es el trabajo, qué tan incierto es y cuánto hay de él. Su único trabajo es comparar una pieza de trabajo contra otra pieza de trabajo del mismo equipo. Una historia de 5 puntos debería ser más o menos cinco veces el esfuerzo de una de 1 punto, para ese equipo, en ese trimestre. Por diseño, no dice nada sobre horas.

Lo cual es un problema, porque las horas son lo que estás comprando.

Esa tensión es todo el tema de este artículo. El canon ágil dice que nunca conviertas story points en tiempo. El canon tiene razón, y a la vez es silenciosamente inútil para la única persona de la sala que tiene que firmar la factura. Las dos cosas son ciertas, y podés sostener las dos si entendés para qué se construyó el instrumento.

Qué mide realmente un story point

Los story points salieron de Extreme Programming a fines de los noventa, y resolvían una falla concreta: los desarrolladores son notoriamente malos estimando horas, y son bastante menos malos estimando proporciones. Preguntale a un ingeniero “¿cuánto va a tardar esto?” y vas a recibir un número moldeado por el optimismo, por quién pregunta y por lo que cree que querés escuchar. Preguntale “¿esto es más grande o más chico que lo que entregamos la semana pasada?” y vas a recibir algo más cercano a la verdad.

Ese es todo el truco. Un punto es una comparación, anclada en trabajo que el equipo ya terminó.

Al número entran tres ingredientes:

• Complejidad. Cuántas partes móviles, cuántas incógnitas en el diseño, cuántos lugares donde puede salir mal. Integrar una pasarela de pagos que el equipo nunca tocó es complejo aunque el código sea corto.
• Incertidumbre. ¿Cuánto de esto es descubrimiento? Una historia que depende de una API de terceros sin documentar carga un riesgo que un campo de formulario no tiene.
• Volumen. La cantidad pura de trabajo. Cuarenta pantallas casi idénticas pueden ser simples y aun así grandes.

Una historia de 8 puntos no es “una de 3 puntos difícil”. Es una historia que el equipo, comparándola contra todo lo que ya construyó junto, cree que es más o menos ocho veces el tamaño de su historia de referencia más chica. Si tu equipo no puede señalar una historia terminada y decir “este es nuestro 1”, sus puntos son decoración.

Eso es lo primero que conviene verificar como comprador. Preguntá cuál es la historia terminada que les sirve de ancla. Un equipo con una respuesta real está estimando. Un equipo sin respuesta está adivinando disfrazado.

Por qué los story points van 1, 2, 3, 5, 8, 13

La mayoría de los equipos estima con una escala Fibonacci modificada: 1, 2, 3, 5, 8, 13, 21. Los saltos se agrandan a medida que crecen los números, y eso es el punto, no un accidente aritmético.

La precisión se derrumba a medida que crece el tamaño. Un equipo puede distinguir de verdad un 1 de un 2. No puede distinguir un 20 de un 21, y si le das la opción, va a pasar cuarenta minutos fingiendo que sí. La escala que se abre empuja la estimación hacia baldes que son honestos sobre su propio margen de error.

La escala también funciona como alarma. Apenas una historia cae en 13 o 21, los equipos disciplinados ni la estiman. La parten. Un 21 no es una estimación, es la confesión de que el trabajo todavía no se entendió. Si ves 21 sobreviviendo hasta dentro de un sprint, esa es una señal para tirar del hilo, y casi siempre significa que las historias de usuario se escribieron demasiado gruesas para poder construirlas.

El 1, 3, 5, 8 por defecto de Jira es la misma idea con menos vocabulario. Nada de la herramienta cambia la lógica.

¿Cuántas horas es un story point?

Es la pregunta más buscada sobre story points y la única que todos los artículos de la primera página de Google se niegan a contestar. La respuesta honesta viene en tres partes.

Parte uno: oficialmente, ninguna. No hay conversión, y Mike Cohn lo viene diciendo desde hace dos décadas. Un punto no es una hora, ni un día, ni medio día. Dos equipos de la misma empresa pueden estar cerrando 30 puntos por sprint y moverse a velocidades reales completamente distintas, porque sus puntos están calibrados contra anclas distintas. Los puntos no son portables entre equipos, y tampoco entre trimestres si el equipo cambió.

Parte dos: tu equipo ya hace la conversión mentalmente. Por supuesto que la hace. Todo desarrollador que alguna vez puntuó una historia pensó “esto es día y medio”. La cuenta existe. Solo que es informal, privada y se recalibra todo el tiempo.

Parte tres: hay una conversión que sí podés calcular, y mira hacia atrás. Tomá lo que el equipo te cuesta realmente en un sprint. Dividilo por los puntos que realmente completó en ese sprint. Eso te da un costo por punto para ese equipo, en ese proyecto, durante ese período. Si un sprint de dos semanas te cuesta 20.000 dólares y el equipo cierra de forma consistente 40 puntos, tu tasa efectiva es de 500 dólares por punto, y ese rehacer de pagos de 13 puntos es una decisión de unos 6.500 dólares.

Ese número es útil. Es el número que te deja decidir si vale la pena construir la funcionalidad, que es tu trabajo, no el de ellos. Y sobrevive al contacto con la realidad, porque sale de lo que pasó y no de lo que alguien esperaba que pasara.

Pero viene con una regla, y la regla sostiene todo lo demás.

En el momento en que los story points se vuelven precio, dejan de ser estimación

Hacé la conversión. No la publiques.

En el instante en que un equipo se entera de que sus puntos se están convirtiendo en dinero y devolviéndoselos, los puntos dejan de medir tamaño y pasan a medir autoprotección. Las estimaciones se inflan, callada y universalmente. Nadie decide hacerlo. Simplemente pasa, como el agua encuentra la pendiente.

Es la ley de Goodhart, en la formulación más afilada que le dio la antropóloga Marilyn Strathern: cuando una medida se convierte en objetivo, deja de ser una buena medida. Los story points son especialmente frágiles acá porque son autodeclarados, no verificables desde afuera, y estimados por las mismas personas cuyo trabajo miden. No existe una auditoría independiente que diga si una historia “era de verdad” un 5. La inflación de puntos es indetectable por construcción. Nunca la vas a agarrar, porque no hay nada contra qué contrastarla.

Ron Jeffries, una de las personas que puso los story points en el mundo, lleva años argumentando que se usan mal exactamente así. Su resumen, en Story Points Revisited, vale los quince segundos que toma leerlo: “Puede que haya inventado los story points y, si lo hice, ahora lo lamento.”

Así que guardate el costo por punto, usalo para tus propias decisiones de construir o saltear, y nunca se lo agites al equipo en una review. Los founders que se equivocan acá terminan con un equipo cuyo gráfico de velocidad se ve espectacular y cuya fecha de entrega no para de correrse. Optimizaron el número y perdieron aquello para lo que servía el número.

Cómo se ven 1, 3, 5, 8 y 13 puntos en un proyecto real

Los puntos no son portables, así que cualquier tabla como esta es un boceto y no un estándar. Pero los founders siguen pidiendo una referencia, y negarse a darla es la razón por la que los artículos existentes sobre el tema son inútiles. Acá va una forma aproximada, calibrada contra el tipo de trabajo que hace de verdad un equipo de producto en etapa temprana:

Dos cosas para llevarse. Primera: el salto de 5 a 8 a 13 es donde vive el riesgo, y ahí es donde deberías poner tu atención en la planificación del sprint. Segunda: si los 13 de tu equipo se parecen a los 3 de otro equipo, no te están cobrando de más. Están calibrados distinto, y la única comparación que importa es contra su propia historia.

La velocity es el número que sí hay que mirar, y cómo leerlo

La velocity es el total de puntos que un equipo completa en un sprint. Promediada sobre los últimos tres a cinco sprints, es lo más parecido a un instrumento de pronóstico que tenés: puntos que quedan en el backlog, divididos por la velocity, te dan los sprints que faltan.

Leela por estabilidad, no por tamaño. Un equipo que hace 32, 30, 34, 31 es un equipo sobre el que podés planificar una ronda. Un equipo que hace 45, 20, 50, 18 es un equipo cuyas estimaciones todavía no significan nada, y su promedio de 33 es una mentira contada con aritmética. La varianza es la señal. Perseguí la varianza, no el techo.

Tres cosas corrompen en silencio un gráfico de velocity, y vale preguntar por las tres:

• Carryover. Puntos que se cuentan cuando una historia a medio terminar pasa al sprint siguiente. Si el trabajo inconcluso puntúa, la velocity deja de significar “entregado”.
• Repuntuación. Una historia que era un 5 el sprint pasado y es un 8 este, sin que el alcance haya cambiado.
• Comparar entre equipos. Dos squads, dos calibraciones. Nunca en el mismo gráfico.

Cuatro preguntas para la planificación cuando no sos técnico

No necesitás entender el código para auditar la estimación. Necesitás entender si la estimación es real. Estas cuatro preguntas hacen eso, y ninguna te exige saber qué es un índice de base de datos.

1. “¿Cuál es su historia de referencia para un 1?” Si no pueden nombrar un trabajo terminado, la escala no tiene ancla y cada número que venga después está inventado.
2. “¿Cuál es la incertidumbre de esta, y qué la haría crecer?” Un buen equipo contesta al instante y con especificidad: “si esa API no soporta reembolsos parciales, esto se duplica”. Un equipo que dice “debería estar bien” no miró.
3. “¿Cuánto puntuamos algo parecido la última vez, y cuánto costó de verdad?” Es el único chequeo de calibración que existe. Los equipos que lo registran mejoran. Los que no, derivan.
4. “¿Cuál es la versión más chica de esto que un cliente podría usar?” No es una pregunta de puntos, pero es la pregunta más valiosa de la sala. Un 8 casi siempre contiene un 3 que habría alcanzado.

Cuándo los story points son el instrumento equivocado

Los story points asumen un equipo continuo, un backlog estable y una relación en la que comprás capacidad a lo largo del tiempo. Si ese no es tu arreglo, son la herramienta equivocada y deberías dejar de pedirlos.

Si firmaste un contrato de alcance cerrado y precio cerrado, los puntos te son irrelevantes. Compraste un resultado, no una tarifa, y el método interno de estimación del proveedor es problema suyo. Si estás en tiempo y materiales, los puntos sirven pero no son el contrato, y la diferencia entre esos dos arreglos pesa mucho más en tu presupuesto que cualquier estimación.

Y si un proveedor te está cotizando en story points en una propuesta, antes de que ningún equipo haya construido nada junto, ese número es decoración. No hay historia compartida contra la cual anclarlo. Los puntos no existen hasta que un equipo terminó trabajo junto, y un punto de un equipo con el que nunca trabajaste es un número sin denominador.

Preguntas frecuentes

¿Cuántas horas son 5 story points?
No hay conversión oficial, y cualquier proveedor que te dé una sin matices te está diciendo lo que querés escuchar. En la práctica: dividí lo que te cuesta un sprint por los puntos que ese sprint entregó, y vas a tener un costo por punto de ese equipo. Usalo para tus decisiones, mantenelo fuera de la agenda de la review.

¿1 story point equivale a 1 día?
No, y los equipos que dejan que esa equivalencia se instale suelen terminar con una escala que es simplemente “días” disfrazada. Cuando eso pasa, perdiste la comparación relativa que hacía útiles a los puntos y te quedaste con todo el overhead.

¿Por qué los story points son 1, 3, 5, 8?
Porque la precisión de la estimación se degrada a medida que el trabajo crece. Los saltos que se agrandan impiden que el equipo discuta diferencias que en realidad no puede percibir, y empujan el trabajo grande y mal entendido hacia un balde que dice “partí esto”.

¿Qué son 5 story points en Agile?
Más o menos cinco veces el tamaño de la historia de referencia más chica del equipo, sumando complejidad, incertidumbre y volumen. En la mayoría de los equipos de producto en etapa temprana esa forma se parece a un flujo autocontenido con sus propios estados y permisos. En tu equipo, es lo que diga la historia de tu equipo.

¿Puedo comparar nuestra velocity con la de otra empresa?
No. Los puntos se calibran por equipo. Una empresa que hace 60 puntos por sprint no es el doble de rápida que una que hace 30. Es otra vara de medir, y la comparación no te dice nada salvo que alguien en la conversación quiere ganarla.