¿Qué son los «story points»? Se trata de estimar el esfuerzo, no el tiempo

Los puntos de historia miden el esfuerzo relativo de una tarea (su tamaño, complejidad e incertidumbre resumidos en una sola cifra), no las horas que llevará realizarla. Se determina el tamaño de un elemento del backlog comparándolo con una historia de referencia que el equipo ya haya entregado («esta es aproximadamente el doble de aquella»), en lugar de adivinar una duración. Ese simple cambio es lo que permite que la estimación resista el contacto con la realidad.

¿Por qué medir el esfuerzo y no el tiempo?

Un equipo que realiza estimaciones en horas, en realidad está realizando dos estimaciones: la que considera válida el ingeniero sénior y la que anota el ingeniero junior tras redondear al alza para dar una imagen de responsabilidad. Las personas no son fiables a la hora de responder a «¿cuánto tiempo llevará esto?», pero son sorprendentemente buenas a la hora de responder a «¿es esto más grande que lo que terminamos en el último sprint?». Los puntos de historia se basan en lo segundo.

La valoración relativa permite al equipo ponerse de acuerdo en que una tarea es más importante que otra sin que nadie se comprometa a una cifra concreta de horas, lo que evita el sesgo de anclaje y de antigüedad que suelen provocar las estimaciones en horas. La cifra resultante no representa una duración, sino una posición en una escala compartida.

Calcular el volumen de trabajo en función del esfuerzo, en lugar de en horas, permite evitar tres problemas que suelen afectar a las estimaciones basadas en horas:

• Una estimación no es un compromiso. Las horas invitan a las partes interesadas a considerar las «8 horas» como una promesa; los puntos hacen que la estimación siga siendo una previsión.
• Una misma tarea lleva a cada persona un tiempo diferente. Un punto refleja el trabajo, no a la persona.
• La duración no tiene en cuenta el riesgo. Una tarea breve pero incierta puede ser más arriesgada que una larga y bien conocida, por lo que los puntos reflejan esa incertidumbre.

La escala y para qué sirven los puntos

La mayoría de los equipos votan siguiendo una escala tipo Fibonacci, 1, 2, 3, 5, 8, 13, en una ronda de planning poker. Las diferencias se amplían a propósito: cuanto mayor es el trabajo, menos sabe realmente cada uno, por lo que la escala deja de pretender que se pueda distinguir un 9 de un 10. Si se suman los puntos que un equipo obtiene al finalizar cada sprint, se obtiene la velocidad, que es precisamente lo que se pretende obtener con los datos de previsión.

Si un elemento supera aproximadamente el nivel 13, eso suele indicar que la escala le está sugiriendo que lo divida en partes que el equipo pueda comprender y completar en un solo sprint.

Para realizar una primera pasada más rápida y aproximada, algunos equipos clasifican todo el backlog según tallas de camiseta y solo convierten en puntos el trabajo a corto plazo una vez que se ha refinado.

En una ronda de «planning poker», todos muestran su carta al mismo tiempo, de modo que nadie se deja influir por la voz más fuerte o por la de mayor antigüedad. Cuando las estimaciones más altas y más bajas divergen, esas dos personas explican su razonamiento, y esa conversación —que saca a la luz los supuestos y la complejidad oculta tras la cifra— suele tener más valor que la propia cifra. La guía completa del «planning poker» explica los mecanismos.

El principal motivo de fracaso es que el equipo empiece a convertir los puntos de nuevo en horas. En el momento en que esa tabla de conversión se publica en la wiki, todas las conversaciones sobre estimaciones se reducen a una discusión sobre la duración y se pierde la noción de esfuerzo relativo.

¿Qué obra debería señalar?

En cada reunión de refinamiento surgen dos preguntas: ¿esto suma puntos siquiera? y, en caso afirmativo, ¿cuántos? La escala sirve precisamente para responder a la pregunta «¿cuántos?». En cuanto a la pregunta «¿suma puntos?», existe una regla general: se deben puntuar todos los elementos que el equipo entregue como parte del trabajo comprometido, de modo que la señal de velocidad refleje a dónde se destina realmente la capacidad.

Errores

Un error cuya causa se conoce y cuya solución es clara constituye una historia. Cuenta con criterios de aceptación («el formulario ya no admite cantidades negativas»), un alcance definido y un tamaño razonable, por lo que debe votarse como cualquier otra historia. El trabajo relacionado con los errores y el trabajo relacionado con las funcionalidades compiten por la misma capacidad, y la velocidad debe reflejarlo.

La excepción es el error cuya naturaleza es «aún no sabemos qué hay ahí»: investigar la corrupción de datos, averiguar por qué se ha duplicado el p99, los clientes siguen informando del problema y no podemos reproducirlo. La corrección no se ha cuantificado porque se desconoce la causa, por lo que una votación de puntos de historia solo mide lo que el equipo espera encontrar. Incluya estos casos en una línea de investigación con un plazo definido: dedique uno o dos días a investigarlos y, a continuación, presente una historia concreta sobre lo que haya descubierto.

Pruebas y control de calidad

Los puntos de historia miden el volumen de trabajo entre el momento en que «la historia entra en el sprint» y el momento en que «la historia está lista para su entrega», lo que incluye cualquier tarea de control de calidad que el equipo realice como parte del proceso de finalización: pruebas automatizadas, verificación manual, comprobaciones de accesibilidad y revisión de seguridad. La historia no se considera «terminada» cuando se fusiona la solicitud de incorporación de cambios (PR); se considera «terminada» cuando cumple con la definición de «terminado».

Los equipos que se centran exclusivamente en el desarrollo y añaden el control de calidad (QA) por separado se comprometen a más de lo que pueden asumir en cada sprint, ya que el control de calidad es el cuello de botella que nadie ha tenido en cuenta. Si un equipo de control de calidad independiente se encarga de las pruebas, la historia sigue conllevando el coste, por parte de los desarrolladores, de colaborar con ellos: preparar la compilación, redactar el plan de pruebas y responder a las preguntas. Esa parte no es gratuita, por lo que se incluye en la estimación.

Por qué rara vez le conviene un artículo de un solo punto

Las puntuaciones son relativas, por lo que un 1 solo tiene sentido cuando se compara con un 2, un 3 o un 8. Cuando un equipo acumula una sucesión constante de noticias de 1 punto, ese gradiente desaparece: todo lo insignificante es un 1, todo lo que es un poco más importante es un 2 o un 3, y la escala se ha reducido a una simple moneda al aire.

La solución no consiste en prohibir los «1» (esa es la versión simplista de la norma). Consiste en preguntarse por qué hay tanto trabajo que se concentra en la parte inferior. Por lo general, la historia de referencia se ha desviado: el equipo ha ganado velocidad y el «1» original es ahora más pequeño que cualquier cosa que lancen al mercado, por lo que debe elegirse una referencia más reciente que el equipo recuerde y volver a establecer el punto de referencia. A veces, el equipo desglosa en exceso durante el refinamiento, separando cada criterio de aceptación como una historia propia: «actualizar el texto del botón» no es una historia, sino un criterio de aceptación de una historia más amplia. Y, en ocasiones, el trabajo es realmente pequeño (una tarea de mantenimiento, un cambio en el texto que requiere revisión jurídica, un ajuste de configuración que afecta al entorno de producción); en ese caso, los puntos cumplen su función y no hay nada que corregir.

La señal a la que hay que prestar atención no es que «nunca haya historias de nivel 1». Es que las historias de nivel 1 constituyan la mayor parte de la cartera de trabajo pendiente. Una o dos por sprint está bien. Si cada dos historias hay una de nivel 1, significa que hace demasiado tiempo que no se ha planteado la cuestión de la calibración.

Los puntos de historia y la retrospectiva

La estimación es uno de los aspectos que el equipo revisa con mayor frecuencia en su retrospectiva de sprint. Cuando los elementos se subestiman o se sobreestiman de forma habitual, cuando la velocidad oscila de manera extrema o cuando el trabajo «finalizado» se vuelve a abrir continuamente, la retrospectiva es el momento en el que el equipo recalibra su percepción compartida del volumen de trabajo y ajusta la forma en que divide las tareas. La precisión de la estimación mejora gracias a ese ciclo de retroalimentación, no por esforzarse más desde el principio.

Preguntas frecuentes

¿Qué son los puntos de historia ágiles?

Los puntos de historia son una unidad de estimación relativa: un número que refleja la magnitud de una tarea (su esfuerzo, complejidad e incertidumbre en conjunto) en comparación con una historia de referencia que el equipo ya ha completado. Se ha evitado deliberadamente que sean una medida de tiempo. El equipo evalúa cada elemento en relación con los demás, en lugar de hacerlo en función del tiempo.

¿Por qué utilizar «story points» en lugar de horas?

Las personas no se les da bien estimar el tiempo absoluto, pero sí saber si una cosa es mayor que otra, y los «story points» se basan en esa capacidad. Además, evitan la trampa de considerar una estimación como un compromiso, tienen en cuenta que una misma tarea requiere un tiempo diferente según la persona que la realice e incorporan la complejidad y el riesgo, no solo la duración. A lo largo de varios sprints, la velocidad de un equipo expresada en puntos se convierte en una previsión más fiable que la suma de las estimaciones en horas.

¿Cómo se calculan los puntos de historia?

La mayoría de los equipos utilizan el «planning poker». Alguien explica una tarea pendiente, el equipo la debate y cada uno elige en privado un valor de una escala común, normalmente una secuencia similar a la de Fibonacci (1, 2, 3, 5, 8, 13). Todos revelan sus valores a la vez; cuando las estimaciones difieren considerablemente, quienes han votado el valor más alto y el más bajo explican su razonamiento y el equipo vuelve a votar hasta alcanzar un consenso. El debate que saca a la luz la complejidad oculta suele ser más valioso que la cifra en sí misma.

¿Deberían asignarse puntos de historia a los errores?

Sí, cuando el error tiene una causa conocida y una solución clara: se trata de una tarea como cualquier otra, y señalarlo permite que la velocidad refleje fielmente a dónde se destina la capacidad. La excepción son los errores exploratorios cuyo alcance aún no se puede determinar; asigne a esos una vía de investigación con un plazo determinado y evalúe el alcance real de la solución una vez que conozca la causa.

¿Se incluyen las pruebas en los puntos de historia?

Sí. Los puntos cuantifican todo el proceso desde que una función se incorpora al sprint hasta que está lista para su entrega, lo que incluye las pruebas y el control de calidad que el equipo lleva a cabo como parte de su definición de «terminado». Si se asignan puntos únicamente al trabajo de desarrollo, el sprint se alarga cada vez, ya que el control de calidad es el cuello de botella que nadie ha tenido en cuenta.

¿Por qué debería evitar las noticias de un solo punto?

Unos pocos están bien. Pero si la mayor parte de la cartera de tareas está compuesta por elementos de nivel 1, la historia de referencia del equipo se ha desviado y la escala se ha desmoronado, por lo que todo se percibe como «pequeño o grande». Recalibre la escala basándose en una historia de referencia reciente, en lugar de reducirla.

¿Se pueden comparar los puntos de historia entre equipos?

No. Un «story point» se calibra en función de la percepción que tiene cada equipo del tamaño relativo de una tarea, por lo que un «5» de un equipo no equivale al «5» de otro. Comparar la velocidad o los totales de puntos entre equipos carece de sentido y, si se utiliza como objetivo, resulta claramente perjudicial: empuja a los equipos a inflar sus estimaciones. Los «story points» son una herramienta de planificación para las previsiones de un único equipo, no un indicador de productividad destinado a la comparación.

Lecturas relacionadas

• Por qué los puntos de historia utilizan la sucesión de Fibonacci: por qué las diferencias se amplían a medida que aumentan los números.
• Puntos de historia frente a horas: la trampa de la conversión y qué hacer cuando alguien necesita una fecha.
• Velocity: convertir los puntos de inflexión en una previsión sin alterarlos.
• Técnicas de estimación ágiles: qué método utilizar en cada caso y en qué aspectos falla cada uno de ellos.
• Retrospectiva de sprint: en la que los equipos reajustan las estimaciones que no se cumplen una y otra vez.
• Guía de estimación ágil: todo lo que hay que saber, desde el «planning poker» hasta la división de historias.
• Planning Poker gratuito para equipos ágiles: evalúen juntos el volumen de su lista de tareas pendientes en tiempo real.