¿Qué son los «story points»? 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 plantean 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 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 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. 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.
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.
- Cada persona tarda un tiempo diferente en realizar la misma tarea. 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.
Cómo funciona la estimación de puntos de historia
La mayoría de los equipos votan según una escala de 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 volumen de trabajo, menos se sabe realmente, 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 evalúan el tamaño de todo el backlog en tallas de camiseta y solo convierten en puntos el trabajo a corto plazo una vez que se ha refinado. ¿Evaluar el tamaño de todo el backlog de una sola vez? Empiece con una estimación por afinidad y asigne puntos a los grupos al final.
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 rango. 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 del juego.
El principal motivo de fracaso es que el equipo comience 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? 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 de su trabajo comprometido, de modo que el indicador de velocidad refleje a dónde se destina realmente la capacidad.
Errores
Un error cuya causa se conoce y cuya solución está 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 trabajo de investigación con plazo limitado: 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 cuantifican el trabajo que se realiza 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 lleve a cabo como parte de la fase «terminado»: 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 centran el trabajo 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 independiente de control de calidad 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 una noticia 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 un simple lanzamiento de moneda.
La solución no consiste en prohibir los «1» (esa es la versión simplista y sin fundamento 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, por lo que hay que elegir una referencia más reciente que el equipo recuerde y volver a fijarla como punto de referencia. A veces, el equipo desglosa en exceso durante el refinamiento, separando cada criterio de aceptación como si fuera 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 se 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» á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 optado deliberadamente por que no 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 «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 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 de la lista de trabajo pendiente, el equipo la debate y cada uno elige en privado un valor de una escala compartida, normalmente una secuencia similar a la de Fibonacci (1, 2, 3, 5, 8, 13). Todos revelan sus votaciones 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 que se alcanza 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 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 las estimaciones. Los «story points» son una herramienta de planificación para las propias previsiones de un equipo concreto, 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 ágiles de estimación: 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.