Técnicas de estimación en SCRUM

Como indica la guía de SCRUM, uno de los atributos que deben tener los elementos del Product Backlog es la estimación, gracias a la cual el equipo SCRUM podrá seleccionar durante la planificación del Sprint, en función de la capacidad que tenga el equipo de desarrollo, los elementos del Backlog que piensa que se podrán acometer dentro del siguiente Sprint.

Aunque como SCRUM se trata de un marco de trabajo y no de una metodología no impone ninguna técnica concreta para llevar a cabo ese proceso de estimación, sino que nos deja libertad para cada equipo escoja el que mejor cree conveniente. SCRUM nos define las reglas del juego, pero no que táctica debemos utilizar para conseguir nuestro objetivo. Es decir, si aplicásemos un símil deportivo por ejemplo con el fútbol, Spring SCRUM nos define cuantos jugadores componen el equipo, el tiempo del partido, etc., pero no con qué alineación debemos jugar.

Un error que no deberíamos cometer a la hora de aplicar SCRUM sería emplear unidades de tiempo, como horas, para llevar a cabo las estimaciones. En su lugar, deberíamos realizar una estimación relativa, ya que a las personas se nos se nos da muy bien acertar exactamente cómo de grande es algo, pero sí se nos da mejor clasificar elementos entre sí en función de su tamaño.

Además, el hecho de que en SCRUM realicemos las estimaciones de manera colaborativa entre todo el equipo nos permitirá obtener estimaciones más certeras que si realizamos una estimación individual basada en horas, como hacemos tradicionalmente cuando aplicamos una metodología en cascada. Por ejemplo, para realizar una misma tarea un desarrollador podría estimar que necesita 20 horas y otro 50, ya que la velocidad de cada uno de ellos puede ser distinta. El hecho de que en SCRUM realicemos una estimación consensuada entre todos los miembros del equipo teniendo en cuenta la capacidad de todo el equipo en su conjunto y no de manera individual nos permitirá obtener una estimación más acertada de qué elementos del Spring Backlog podrá acometer el equipo de desarrollo dentro de un Sprint.

A continuación, vamos a mostrar algunas técnicas que podemos emplear a la hora estimar los elementos del Product Backlog.

Planning Poker

Los participantes emplean cartas con una numeración especial que asignan a cada uno de los elementos del Product Backlog. Después de estimar un elemento del Product Backlog, las personas que han otorgado la mayor y la menor puntuación explican los motivos por los que han escogido dicha puntuación y se vuelve a realizar la estimación, así hasta que se llegue a un consenso.

La numeración de las cartas está basada en una serie de Fibonnacci (0, 1, 2, 3, 5, 8, 13, 21 34, etc.), aunque en ocasiones se pueden varían algunos números de la serie (1, 2, 3, 5, 8, 13, 20, 40, 100, etc.). La razón de emplear una serie de Fibonnacci o similar es que, aunque como hemos dicho antes, a las personas se nos da bien clasificar elementos entre sí en función de su tamaño, cuanto más grandes son esos elementos y menos diferencia hay entre ellos, más difícil se nos hace poder discernir las pequeñas diferencias. Por ejemplo, entre una encina de 20 metros y un limonero de 5 metros, podemos decir claramente cual es más grande, pero con entre dos secuoyas, una de 101 metros y otra de 102 la cosa se complica.

T-Shirt Sizes

Esta técnica se basa en asignar tallas de camiseta (XS, S, M L, XL) a la hora de estimar en vez de utilizar números, lo cual puede ayudar a que los miembros del equipo a adoptar la idea de una estimación relativa desasociando el valor de la estimación de un elemento del Product Backlog con el número de horas equivalente necesarias para su implementación.

Bucket System

Al igual que en el Planning Poker, también en una secuencia numérica, colocándose todos los números de la secuencia ordenados uno seguido de otro como si se tratase de cubos, usando ya sea papeles o por ejemplo una cesta, de manera que se estiman cada uno de los elementos del Product Backlog poniéndolos en el cubo correspondiente.

Dot Voting

En esta técnica cada miembro el equipo tiene un número de etiquetas o fichas que puede repartir entre los distintos elementos del Product Backlog, de forma que cuantas más fichas se hayan asignado a un elemento del Product Backlog mayor será su tamaño.

Conclusión

Como hemos comentado antes, SCRUM no impone ninguna técnica específica de estimación, en base al contexto en el que nos encontremos deberemos escoger aquella con la que el equipo se sienta más cómodo y que se adapte mejor a nuestras necesidades. Por ejemplo, en el caso de que debamos estimar un elevado historias de usuario sería preferible emplear por ejemplo T-Shirt Sizes, en vez de Planning Poker o Dot Voting, ya que están técnicas funcionan mejor con un pequeño número de historias de usuario. También conviene prestar atención a si el equipo se encuentra en la misma localización o si está distribuido, sobre todo en estos tiempos, en los que cada vez se fomenta más el teletrabajo y pueden surgir situaciones que impidan que los miembros del equipo se encuentren en la misma localización, como el COVID-19, para poder establecer una forma en la que las estimaciones se puedan realizar de forma distribuida. Por ejemplo, a través de la web planningpoker.com podemos realizar estimaciones cuando trabajamos con equipos de gente trabajando en remoto.

También es importante resaltar que las estimaciones en SCRUM no deben entenderse como un compromiso adquirido por el equipo de trabajo a modo de pacto firmado con sangre, SCRUM se basa en la heurística, por lo que las estimaciones de los elementos del Product Backlog y de las tareas del Spring Backlog se deberán irse reestimándose en base a la experiencia adquirida. Es normal que al empezar a emplear SCRUM las estimaciones iniciales no sean muy acertadas, pero según vayamos realizando más ciclos de Sprint y el equipo vaya adquiriendo mayor experiencia podremos conocer mejor la capacidad del equipo de desarrollo para un Sprint y las estimaciones se irán ajustando cada vez más a la realidad.