¿Qué son los puntos de historia? Se trata de estimar el esfuerzo, no el tiempo
La estimación en puntos de historia mide el esfuerzo relativo, la complejidad y la incertidumbre del trabajo, no las horas. Cómo realizar la estimación en comparación con una historia de referencia, y las preguntas que suelen plantear dificultades a los equipos.
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 de la lista de tareas pendientes comparándolo con una historia de referencia que el equipo ya haya entregado («esta es aproximadamente el doble de aquella»), en lugar de adivinar su 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 parecer responsable. A las personas no se les da bien responder a la pregunta «¿cuánto tiempo llevará esto?», pero sí se les da sorprendentemente bien responder a «¿es esto más grande que lo que terminamos en el último sprint?». Los puntos de historia se basan en lo segundo.
El tamaño relativo permite al equipo ponerse de acuerdo en que una tarea es más grande que otra sin que nadie se comprometa a una cifra en horas, lo que evita el sesgo de anclaje y de antigüedad que suelen provocar las estimaciones en horas. La cifra resultante no es 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 un tiempo diferente a cada persona. Una puntuación 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.
Cómo funciona la estimación de puntos de historia
La mayoría de los equipos votan según 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á indicando 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 jerarquía. 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 detrás de 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 destacar?
En cada reunión de refinamiento surgen dos preguntas: ¿esto suma puntos? 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 entrega como parte de su 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 debería 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 real basada en 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 «hecho»: pruebas automatizadas, verificación manual, comprobaciones de accesibilidad y revisión de seguridad. La historia no se da por terminada cuando se fusiona la solicitud de incorporación de cambios (PR); se da por 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 trabajar 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 conviene que una noticia se centre en 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, así que elija una referencia más reciente que el equipo recuerde y vuelva 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 a la 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 con puntuación 1». Es que las historias con puntuación 1 constituyan la mayor parte de la lista de tareas pendientes. Una o dos por sprint está bien. Si cada dos historias hay una con puntuación 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 sobreestiman de forma habitual, cuando la velocidad oscila de manera extrema o cuando el trabajo «finalizado» se vuelve a abrir, 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 «story points» en el método ágil?
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 optado deliberadamente por que no sean una medida de tiempo. El equipo evalúa cada elemento en relación con los demás, y no en función del tiempo.
¿Por qué utilizar «puntos de historia» en lugar de horas?
A las personas les cuesta estimar el tiempo absoluto, pero se les da bien juzgar si una cosa es mayor que otra, y los «story points» se basan en esa fortaleza. 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 esos a una vía de investigación con un plazo definido 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?
Unas pocas están bien. Pero si la mayor parte de la lista de tareas pendientes 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 a un «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 aciertan 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.