Estimar historias de usuario

Hay diversas técnicas que nos ayudan a estimar tareas o, lo que nos ocupa en esta artículo, historias de usuario. Cierto es que en el mundo del agilismo lleva sonando fuerte una tendencia #NoEstimates, que básicamente considera que el tiempo invertido en las estimaciones es despedicio. Y, aunque el argumentario tiene algunos puntos que, personalmente, soy capaz de comprar, la realidad del día a día nos dice que muchas ocasiones el estimar o no estimar no es una opción: tenemos que hacerlo.

¿Es posible no estimar nada en absoluto? Yo no digo que no, pero no me he encontrado todavía con una situación que lo propiciara de forma natural, llevando más de 100 proyectos a mis espaldas. Quizás lo más parecido es conseguir que todas las historias de usuario tengan el mismo tamaño, lo que evita tener que estimar, pero eso es algo bastante complejo en la práctica ya que, o bien no es posible por las características de los desarrollos, o bien se fuerza y acaba siendo contraproducente porque dividimos las historias de manera incorrecta. ¿Se puede hacer? Sí, pero es complejo y no depende exclusivamente de ti.

En cualquiera de los casos, lo que sí es cierto es que cuanto menos tiempo necesitemos para estimar mejor. Este tiempo que invertimos en estimar son horas en que no estamos desarrollando el producto. Lo mejor es encontrar la manera de que seamos fiables estimando y, a la par, necesitemos dedicarle el menos tiempo posible. Por ello, vamos a ver un par de sistemas estimación clásicos en el mundo del agilismo que pueden ayudarte.

Planning Poker

El Planning Poker es una técnica de estimación grupal tanto de tareas como de historias de usuario. Ha sido la técnica favorita de muchos Product Owners durante años, aunque ahora mismo el movimiento #NoEstimates sea reacio a su uso. Personalmente, considero que es buen sistema, aunque eso no lo hace exento de pegas, como con cualquier otra técnica.

La manera de ejecutar el Planning Poker es sencilla, tan sólo hay que seguir una serie de pasos en el siguiente orden:

1. El PO lee una historia de usuario, y responde cualquier duda que tengan los miembros del equipo de desarrollo, hasta que no quedan dudas sobre el comportamiento que se espera como resultado.
   
2. Cada miembro del equipo cuenta con una serie de cartas. Estas cartas pueden contener bien la sucesión de Fibonacci (0, 1, 2, 3, 5, 8, 13, 21, 34…), bien un dimensionamiento numérico del 1 al 10, bien un sistema de tallas (XS, S, M, L, XL, XXL, XXXL).
   
3. Cada miembro del equipo de desarrollo selecciona una carta, equivalente al esfuerzo estimado que le otorga a la tarea/historia de usuario, y la pone boca abajo.
   
4. Cuando todos los miembros del equipo tengan seleccionada una carta, se ponen boca arriba todas a la vez.
   
5. Una vez mostradas las cartas, se debate hasta conseguir la unanimidad. La idea es que cuando haya diferencias importantes entre las estimaciones de unos y otros, cada uno justifique su enfoque, hasta que todos lleguen a un acuerdo del esfuerzo requerido para la realización de la tarea o historia de usuario.

Como veis, es muy sencillo. La gran duda que podéis haceros es por qué se suele recomendar que las cartas estén puntuadas con la sucesión de Fibonacci. Esto es porque los humanos no somos muy buenos estimando en función de valores absolutos, pero sí se nos da mejor estimar en valores relativos. Y eso es algo que nos da la sucesión de Fibonacci, ya que cada término de la misma es la suma de los dos términos anteriores, lo que hace que su valores crezcan de forma no gradual. Eso nos da pié a poder valorar, por ejemplo, que una historia de usuario es mucho más compleja que otras y que debe ser dividida en más historias para poder estimar con valores más bajos.

También es posible que en la baraja nos encontremos con una carta con un valor cero (significa que el esfuerzo que requiere la historia de usuario es despreciable, casi nulo), un símbolo de infinito (la historia de usuario no es estimable) o un café dibujado (eso significa que alguien está pidiendo un break, un descanso).

Por otra parte, lo bueno de esta técnica es que abre debate entre el equipo y permite que salgan a la luz diferentes enfoques de abordaje sobre una historia de usuario. Al final, prevalecerá la solución más eficiente, y con ella se evaluará el coste en esfuerzo que supone. Por otra parte, es una técnica que es fácilmente ejecutable en remoto, sin la necesidad de que el equipo esté emplazado en el mismo lugar.

Algunos recursos que nos pueden ayudar serían:

• https://www.planitpoker.com/
• https://www.scrumpoker.online/

Sistema de los cubos o bucket system

Otro sistema que se utiliza para estimar historias de usuario o tareas es el bucket system. Es un sistema colaborativo que tiene ciertas similitudes con el planning poker.

La forma de ejecutar este sistema sería la siguiente:

1. Cogemos todas las historias de usuario a valorar, las explicamos al equipo, se resuelven dudas y cuando todo el mundo la comprenda bien, podremos pasar al paso 2.
   
2. Colocamos unos cubos (no necesariamente tienen que se cubos, pueden ser post its, folios o lo que se nos ocurra) de forma horizontal en una mesa, y señalamos a cada uno con un número entre los siguientes: 0, 1, 2, 3, 4, 5, 8, 13, 20, 30, 50, 100, 200.
   
3. Se coge, al azar, una de las historias del backlog y se coloca en el cubo con el número 8. Con esto ya tenemos una historia de usuario de referencia.
   
4. Se coge, otra vez al azar, una historia del backlog. Teniendo como referencia la anterior historia ubicada en el cubo 8, ahora nos toca colocar esta en el cubo apropiado. Por ejemplo, si vemos que requiere más o menos la mitad de esfuerzo que la primera, la pondríamos en el cubo 4.
   
5. Se repite el paso 3 con un nuevo elemento.
   
6. Con estos casos, tenemos que valorar si nos encontramos con que la primera historia era demasiado sencilla o compleja, y si al ponerla en el cubo 8 no permite valorar correctamente el resto de elementos bajo esa escala. En ese caso, deberíamos hacer lo siguiente:
   
   1. Replantearnos si la historia de usuario está bien. Si es demasiado grande quizás debería dividirse en historias más pequeñas.
      
   2. Sacamos la historia del cubo 8 y la ponemos donde corresponda. Las otras dos historias, si necesitan recolocarse, lo hacemos también.
      
7. Ahora cogemos todas las historias restantes y las repartimos entre el equipo al azar.
   
8. Cada miembro del equipo coloca sus elementos en los cubos que considere apropiados en función del esfuerzo que requiera alguno. Si alguien tiene una historia de usuario que no entiende o que no está preparado para evaluar, puede ofrecérsela a otro miembro del equipo.
   
9. Todos el equipo revisa cómo han quedado los cubos. Si alguien no está de acuerdo con alguno de los resultados, se abre un debate hasta que se llega a un consenso y se coloca en otro cubo o se deja donde estaba.
   
10. Con todo el mundo de acuerdo, ya tenemos la estimación de esfuerzo de cada tarjeta (historia de usuario).

Este sistema es más rápido que el Planning Poker. El problema que tiene es que pueden haber historias de usuario que necesiten de la opinión de varios perfiles de distinto ámbito (un diseñador y un desarrollador, por ejemplo) y eso haga que las estimaciones no sean todo lo precisas que nos gustaría. Cierto es que este problema trata de resolverse en el punto 9, pero es menos ágil que el Planning Poker ante esta misma situación. Juzga si tu proyecto se verá beneficiado de este sistema o si prefieres usar una alternativa.

Conclusión

Existen más técnicas para estimar tarjetas en el mundo ágil. Los sistemas como el T-Shirt Sizes, el Dot Voting o el Large/Uncertain/Small son otras técnicas que, en el fondo, comparten mucho con el Planning Poker y el Bucket System. Aquí hemos comentado las dos que, en principio, mejor funcionan, pero siempre es bueno tener en cuenta alternativas por si las características de un proyecto nos invitan a usarlas.

Lo más importante no es qué técnica uses, sino que el equipo pueda estimar en buenas condiciones y con cierta veracidad. No es tan importante cuándo vas a entregar cierto desarrollo sino el hecho de que tengamos un cierto control sobre la capacidad del equipo para entender qué compromisos podemos adquirir en cada iteración de nuestro proyecto. Además, el hecho de que nos «obliguen» a estimar nos ayuda a querer comprender mejor las tarjetas y sus implicaciones.

Y, aunque decíamos al principio del artículo que ahora la tendencia es no estimar, la realidad es que llegar a ese punto es harto complicado. Eso no quita para que mejoremos con la intención de llegar hasta ahí, pero es un camino demasiado complejo como para aventurarse a pecho descubierto.