Puntos de historia sin misterio
Los puntos de historia, o story points, sirven para decir cuánto pesa un trabajo comparado con otro. Un 8 no significa ocho horas ni ocho días: significa que el equipo ve esa historia bastante más grande que una de 3 y algo más pequeña que una de 13. La unidad no tiene valor absoluto: solo cobra sentido al comparar historias entre sí. Es la medida más extendida en la estimación ágil, sobre todo en equipos que trabajan con Scrum o XP.
Qué cabe en un punto
Cuando alguien elige una carta está mezclando, casi siempre sin pensarlo, tres cosas.
La primera es la cantidad de trabajo. En la app de reparto de comida, mostrar el precio del envío en la ficha de un restaurante es poca cosa; rehacer la ficha entera con fotos, horarios y reseñas es mucho más.
La segunda es la dificultad. Calcular ese precio de envío según la distancia, la hora y la lluvia puede ocupar cuarenta líneas de código y aun así dar muchos quebraderos de cabeza.
La tercera es lo que todavía no se sabe. Si el cálculo depende de una API de mapas que el equipo nunca ha usado, o de reglas que el área comercial aún no ha cerrado, la historia es más arriesgada, y el riesgo se paga en puntos.
Nadie puntúa cada parte por separado. Dos personas pueden elegir el mismo 5 por motivos opuestos, una porque ve mucho trabajo sencillo y otra porque intuye un problema con los mapas. Por eso compensa que las cartas se destapen a la vez y que se hable de las diferencias, que es lo que busca el planning poker.
Por qué no en horas
Las horas tienen a su favor que todo el mundo las entiende, dentro y fuera del equipo. Aun así, estimar en tamaños relativos suele dar mejores resultados, por varias razones.
Comparar es más fácil que medir. Casi nadie sabe cuántos kilómetros hay entre dos barrios de su ciudad, pero casi todos saben cuál de dos trayectos es más largo. Con el software ocurre algo parecido: «¿esto es más grande que el filtro por tipo de cocina?» se contesta mejor y con más coincidencia que «¿cuántas horas lleva?».
Las horas dependen de quién haga el trabajo. El desarrollador que montó el sistema de pagos cambia una comisión en una mañana; alguien que llegó hace un mes necesita tres días para lo mismo. El punto describe la tarea, no a la persona, así que todo el equipo puede ponerse de acuerdo en uno.
Una cifra en horas se convierte enseguida en promesa. Si el ticket dice «16 horas», alguien lo leerá como «para el jueves», y quien se pase se sentirá en falta. Un tamaño invita menos a esa lectura y deja más espacio para hablar del riesgo.
Y las horas no recogen lo que rodea al código: revisiones, reuniones, esperar a que otro equipo despliegue, un entorno de pruebas caído. La velocidad del equipo (velocity), al medir lo que realmente se terminó, ya lleva todo eso dentro.
Las historias de referencia
Estimar en relativo exige un punto de partida. Antes de la primera sesión, el equipo elige una o dos historias ya terminadas que todos recuerden y les pone valor.
En la app de reparto podría ser así: «mostrar el tiempo estimado de entrega en la ficha del restaurante», que salió sin sorpresas, se queda como un 3. «Filtrar restaurantes por tipo de cocina y rango de precio», con su parte de backend y sus pruebas, se queda como un 8. A partir de ahí la pregunta en cada votación es sencilla: ¿se parece más al tiempo de entrega o al filtro? ¿Está por encima o por debajo?
Conviene tener esas dos historias a la vista, en la cabecera del backlog o fijadas en el canal del equipo. Al cabo de unos meses la escala está en la cabeza de todos, pero a quien se incorpora le hacen falta los ejemplos.
Velocity: para qué sirven los puntos
La velocity es la suma de los puntos de las historias terminadas en un sprint. Si en dos semanas se cierran historias de 8, 5, 3, 13, 2 y 1, la velocity de ese sprint es 32. Lo que quedó al 80 % no cuenta; parece injusto, pero evita que la cifra se infle con trabajo a medias.
Un sprint aislado no dice mucho. Con cuatro o cinco empieza a verse una franja, por ejemplo entre 28 y 35 puntos, y es esa franja la que sirve para planificar. El equipo la usa para no comprometerse de más, y el product owner, para hacer previsiones: si al lanzamiento le quedan unos 180 puntos y la velocity ronda los 30, cabe esperar unos seis sprints, con bastante margen de error.
Si el equipo es estable y el tipo de trabajo no cambia mucho, la velocity suele asentarse. Unas historias se quedan cortas y otras se pasan, y en la suma de un sprint muchos de esos errores se compensan. Lo que la desestabiliza son los cambios frecuentes de personas, los sprints llenos de urgencias y una escala que se va moviendo sin que nadie lo decida.
Cómo se usa la velocity en el refinamiento y en la Sprint Planning está en la página de scrum poker.
Malentendidos frecuentes
«Un punto son cuatro horas»
Es la conversión que alguien acaba proponiendo, normalmente para rellenar un informe. En el momento en que un punto equivale a un número fijo de horas, se vuelve a estimar en horas, con un paso más y con los mismos problemas. Si hace falta una fecha, lo honesto es calcularla en sprints a partir de la velocity.
«Así podemos comparar equipos»
En una misma empresa, el equipo de pagos cierra unos 34 puntos por sprint y el de catálogo ronda los 70. Sería absurdo concluir que catálogo trabaja el doble: sus historias de referencia son otras, y lo que allí vale 13 quizá sería un 5 en pagos. Cuando la dirección insiste en comparar, los equipos aprenden a inflar las estimaciones: la velocity sube, la entrega no, y la cifra deja de servir para planificar.
«La velocity tiene que subir cada sprint»
Para planificar interesa que sea previsible. Cuando pasa de 30 a 45 en un sprint, lo más probable es que la escala se haya movido; un equipo rara vez mejora tanto de golpe.
«Los puntos miden a las personas»
Los puntos se asignan a historias y la velocity pertenece al equipo. Repartirla entre personas para evaluar a cada una destroza la confianza que hace falta para votar con sinceridad.
«Hay que acertar el número exacto»
Los puntos son aproximados a propósito. La mayoría de los equipos usa una escala tipo Fibonacci en la que los saltos crecen con los números, así que nadie discute si algo es un 11 o un 12.
Primeros pasos
Para un equipo que no ha usado nunca puntos de historia, un arranque sin presiones puede ser este:
- Elegir entre todos una historia de referencia pequeña y otra mediana.
- Usar la baraja estándar: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, «?» y ☕.
- Estimar con planning poker solo lo que entrará en los dos próximos sprints. El resto del backlog puede esperar.
- No preocuparse por acertar durante los primeros sprints; la escala tarda en asentarse.
- Anotar la velocity de cuatro o cinco sprints antes de fiarse de ella para planificar.
- Revisar las historias de referencia al cabo de un par de meses. Si se oye mucho «esto es más grande que nuestro 8 de antes», toca recalibrar.
Habrá estimaciones que fallen por mucho. Un 3 que acaba ocupando una semana es un buen tema para la retrospectiva: casi siempre deja una pista para estimar mejor la siguiente historia parecida.