Estimando esfuerzo relativo con Story Points
A muchos equipos, incluso a algunos con mucha experiencia con Scrum, les cuesta entender el significado de los Story Points al estimar sus historias de usuario, lo cual puede llevarlos a planificar un sprint con más tareas de las que pueden terminar.
Por eso, la idea de este post es entender las distintas unidades que existen, sus pros, contras, ejemplos, y, sobre todo, comprender cómo usar los Story Points de forma efectiva.
Unidades
A la hora de proveer estimaciones, es posible hacerlo en distintas unidades, cada una de ellas tiene sus ventajas y sus desventajas. Vamos a repasarlas.
Horas
Los PBI (Product Backlog Items) pueden estimarse en Horas, aunque no vamos a hablar de “horas hombre”, que es como comúnmente se las llama. Cuando decimos que un PBI está estimado en 5hs, estamos hablando del tiempo que nos demandará desarrollarlo.
La ventaja de esta unidad es que es fácil de entender y fácil de explicar por fuera del equipo. Todos van a saber qué queremos decir cuando decimos que ese PBI nos va a llevar 5hs.
La mayor desventaja es que dan una falsa sensación de precisión: una vez que decimos que algo “nos va a llevar 5hs”, si no terminamos en ese lapso, nos van a preguntar qué pasó.
Otra desventaja es que, al tratarse de un valor absoluto, es difícil ponerse de acuerdo al momento de estimar: ¿las 5hs de quién son? ¿es un promedio del equipo? ¿depende del seniority de quién la tome? ¿qué pasa si la encara más de una persona?
Días Ideales
Otra unidad que suele usarse para proveer una estimación son los Días Ideales.
En la propia definición está la mayor desventaja: ¿Cuánto dura un día ideal? El equipo suele definirlo teniendo en cuenta cosas como “un día en el que sólo nos dedicamos a trabajar en el PBI”, “un día sin reuniones”, “un día sin interrupciones”, “el día laboral menos dos horas para cubrir cualquier otra cosa que pueda pasar”, etc. El equipo, entonces, tiene que ponerse de acuerdo en esa definición.
Pero aún cuando lleguen a un punto en común surge otro problema: “mis días ideales no son iguales a tus días ideales”. No todos los miembros del equipo tienen la misma cantidad de reuniones e interrupciones, por lo cual es difícil homogeneizar esta medida.
De todas maneras, puede ser una unidad fácil de entender por fuera del equipo y también puede ser un buen punto de partida para empezar a estimar.
Talles de Camiseta
En este caso, estimamos los PBI clasificándolos por tamaño relativo según los talles de camiseta: XS, S, M, L y XL.
Como desventaja, tenemos que resolver preguntas del estilo: ¿Cuánto más grande es un M que un S? Otra desventaja es que no son aditivos, es decir, no los podemos sumar: ¿Cuánto es un S más un L? Esto no nos pasa si utilizamos horas o días ideales: estimamos que realizar un PBI de 6hs y otro de 4hs nos va a llevar 10hs.
Los talles de camiseta pueden ser útiles para estimar un backlog grande en poco tiempo o a alto nivel, o, para empezar a estimar considerando esfuerzo relativo. En el momento en que llegamos a establecer, por ejemplo, que un S es 1 vez más grande que un XS y que un M es 5 veces más grande que un XS, nuestra escala: XS, S, M se transforma en 1,2,5.
Y esto nos deja a un paso de los story points.
Story Points
Habiendo repasado algunas unidades usuales para expresar estimaciones, llegamos a los Story Points, que es la unidad en la que la mayoría de los equipos Scrum utiliza para las estimaciones de sus PBI.
Para entender qué son los Story Points podemos desarmar su definición:
Unidad de estimación para expresar el esfuerzo relativo que le implica a un equipo llevar una User Story (o PBI) a Done.
Usualmente aplicamos estimaciones en Story Points a User Stories, de ahí su nombre. Pero podría utilizarse en cualquier otro tipo de PBI con el que trabajamos.
El Done es el estado final del PBI, cuando lo consideramos terminado según la Definition of Done (DoD) acordada. Es decir, estamos expresando en Story Points el esfuerzo que nos implica terminar ese PBI.
Cuando hablamos de Relativo, queremos decir que los valores asignados por sí solos no significan nada, lo que importa es la relación con los demás. Por ejemplo, una historia de 3SP implica tres veces más esfuerzo que una historia de 1SP.
Usamos estimaciones relativas porque somos mejores estimando algo en comparación con otra cosa (“esto es como aquello” o “esto es el doble que aquello”). Por ejemplo, es más fácil estimar que, desde CABA, Mendoza está 4 veces más lejos que Rosario, en vez de decir a qué distancia en kilómetros queda cada uno (1024 y 280 km).
Cada equipo tiene su propia definición de qué es 1SP. Una vez que nos pongamos de acuerdo en eso, podemos estimar los siguientes PBI comparándolos en relación a ese valor de 1. Es por eso que los 5SP de un equipo no son iguales que los 5SP de otro porque partieron de una base distinta.
Pero dentro del equipo un PBI de 5SP requiere el mismo esfuerzo que otro PBI de 5SP, básicamente porque ya tienen una escala asignada y consensuada.
A la hora de estimar en story points pensamos en esfuerzo no en tiempo, y tenemos que consideramos 4 dimensiones:
- Volúmen. Es decir, la cantidad de trabajo a hacer (esto es lo que generalmente siempre consideramos cuando estimamos tiempo)
- Complejidad. Qué tan difícil es hacer lo que tenemos que hacer. Por ejemplo, una pantalla simple que requiera aplicar algún algoritmo en el backend es más compleja que la misma pantalla sin ese algoritmo.
- Riesgo. Qué tan riesgoso es realizar eso que tenemos que hacer. Por ejemplo, una historia de usuario que implique pasar por una porción de código que no tiene tests unitarios, o agregar una bifurcación a una parte crítica del código.
- Incerteza. Qué tan bien está definido lo que se espera o qué tan bien sabemos hacer lo que tenemos que hacer. Por ejemplo, una historia de la cual sólo conocemos el título (historias flancito), u otra historia que implique utilizar una librería o tecnología que aún no conocemos.
Cada una de estas dimensiones agrega esfuerzo por sí solo. Existirán, por ejemplo, historias en las que sólo consideremos volumen, otras en las que el riesgo se lleva todo el esfuerzo, y todas las combinaciones que puedan suceder.
Ejemplo
Veamos cada una de estas dimensiones con un ejemplo.
En nuestro backlog, hay una historia que implica realizar un formulario para cargar datos que contiene dos campos de texto, con nombres y validaciones definidas, y un botón para submitear dichos datos. Los valores ingresados se cargan tal cual como vienen en una base de datos. El equipo acordó que esta historia les va a llevar 1SP
A su vez, el mismo equipo tiene otra historia en el backlog para realizar un formulario parecido pero con dos campos de texto más, con las mismas consideraciones que la historia anterior. A la hora de estimar, el equipo considera que le llevará más esfuerzo porque hay más campos. Entonces, teniendo en cuenta el volumen, estiman esta historia en 2SP.
Otra historia de usuario del backlog tiene otro formulario con dos campos. Esta vez, en lugar de tratarse de campos de texto tenemos un selector y un date picker. Son componentes distintos: el selector tiene datos precargados y el date picker debe respetar un formato de fechas definido. El equipo considera que esta historia requiere mayor esfuerzo que la original porque tiene mayor complejidad. Así, deciden estimarla en 2SP.
La próxima historia del backlog no llegó a refinarse bien. Lo único que sabemos de este formulario es que son dos campos de texto. No sabemos su longitud máxima de caracteres permitidos, sus nombres, si tienen validaciones o no, ni cuáles son esas validaciones. Teniendo en cuenta la incerteza de esta historia, el equipo decide asignarle una estimación mayor a la original de, por ejemplo, 3SP.
La última historia del backlog es otro formulario: tenemos los dos campos de texto originales, pero al submitear los datos se pasa por una porción de código que no tiene tests unitarios, por lo cual, cualquier cambio que se haga, puede hacer que se rompa toda la funcionalidad ya desarrollada. Dado que realizar esta historia de usuario implica mayor riesgo que la original, el equipo decide asignarle una estimación de 3SP.
Rara vez estas dimensiones aparecen de a una. Lo típico es que al estimar una historia de usuario se analice cómo contribuye cada una de ellas al esfuerzo total. Lo importante es que esas cuatro dimensiones son puntos de conversación del equipo para acordar la estimación.
Beneficios de Story Points
Al igual que los talles de camiseta y a diferencia de las horas y los días ideales, los story points son medidas de esfuerzo relativo, no de tiempo absoluto.
Debido a esta característica, hay menos discusiones a la hora de estimar, ya que es más difícil ponerse de acuerdo que con valores absolutos.
Al tratarse de medida de esfuerzo, las estimaciones no decaen en el tiempo: dos veces más es siempre dos veces más. Las estimaciones de tiempo siempre van a depender de algún factor externo.
Con respecto a los talles de camiseta, los story points son aditivos: podemos decir que un PBI de 2SP y otro de 3SP nos llevan un esfuerzo de 5SP.
Pero la mayor ventaja de los story points es que permiten que los miembros del equipo con diferentes niveles de skills se comuniquen y acuerden sobre una estimación.
Por ejemplo: Fran y Marce quieren estimar cuánto les lleva correr 300m. Fran, que está en mejor estado físico, dice 5 minutos, Marce 10. No se ponen de acuerdo.
Pueden recurrir a dos soluciones de compromiso, ambas malas:
- El peor caso
- El promedio
Cuando empezamos a querer estimar mayores distancias, por ejemplo 900m, Fran dice 15 minutos y Marce 30. Pero ambos pueden acordar que correr 900 metros les lleva a ambos tres veces más que correr 300m (3SP y 1SP)
Por lo tanto, los story points son una medida más abstracta que considera personas con diferentes skills.
Conclusiones
A la hora de estimar un PBI es necesario entender que puede hacerse con unidades de tiempo o con unidades de esfuerzo relativo. Si bien las primeras pueden ser útiles bajo algunas circunstancias, la mayoría de los equipos Scrum eligen las segundas.
Dentro de ellas, los talles de camiseta suelen ser útiles para estimar backlogs grandes en poco tiempo o al alto nivel, o como una primera aproximación a los Story Points.
Sin embargo, los Story Points son los preferidos por la mayoría de los equipos, por lo que es importante entender bien su concepto y reforzarlo de vez en cuando.
En la Planning de un equipo experimentado en el uso de Story Points, las discusiones y argumentaciones sobre las estimaciones que realizan suelen fundamentarse con frases del estilo “esta historia es más grande porque tiene mayor complejidad” o “esta es más riesgosa que la anterior, pero la anterior incluía más incerteza”. Estas frases incluyen las 4 dimensiones de esfuerzo y hacen referencia a que lo que se está estimando es relativo a otra estimación.
Lo importante es recordar que todo lo que se necesita saber a la hora de estimar en Story Points es si una historia de usuario en particular requiere más o menos esfuerzo que otra.
