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

Los puntos de historia miden el esfuerzo relativo, la complejidad y la incertidumbre del trabajo, no las horas. Cómo determinar el tamaño en comparación con una historia de referencia, y las dudas 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— y no las horas que llevará realizarla. Se evalúa 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.

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 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 es una duración, sino una posición en una escala compartida.

La escala y para qué sirven los puntos

La mayoría de los equipos votan según una escala de 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—.

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 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 tanto, véotelo 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í dentro»: 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 descubrir. 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 hallado.

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 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, 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 independiente: «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 menor, 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.

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 —es decir, su esfuerzo, complejidad e incertidumbre en conjunto— en comparación con una historia de referencia que el equipo ya haya 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.

¿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 realiza el equipo 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 lista de tareas pendientes está compuesta por «1», la historia de referencia del equipo se ha desviado y la escala se ha desmoronado: todo se percibe como «pequeño» o «más grande». Recalibre la escala basándose en una historia de referencia reciente, en lugar de reducirla.

Lecturas relacionadas