El uso de #NoEstimates en una empresa de desarrollo de software

Hace unos días publicábamos un artículo sobre la herramienta NoEstimates, sobre sus fundamentos y orígenes.
Nos gustaría en este nuevo artículo, compartir experiencias con el uso de “no estimar” en una empresa de desarrollo de software.
 

Buscando predictibilidad

Éramos una empresa pequeña que se dedicaba al desarrollo de productos para varios clientes. La empresa fue adquirida por una gran multinacional para desarrollar una nueva rama de su negocio. En un momento dado se gana un concurso para desarrollar una solución entera para un tercero. Se requería un conjunto de productos, algunos de los cuales ya se estaba trabajando y otros que teníamos de crear de cero.
 
Para poder concretar estos acuerdos necesitábamos predictibilidad. La predictibilidad nos permite establecer fecha a nuestros compromisos comerciales, nos permite gestionar las expectativas de nuestros usuarios o clientes, saber si llegaremos a la fecha comprometida con el alcance establecido. Aunque esto no parece muy Agile, es la realidad de muchas de las empresas, tienen fijados el alcance y la fecha de entrega de sus productos o proyectos.
 

 
Si bien es cierto que las estimaciones nos ayudan a tener predictibilidad, la cual es fundamental en la gestión de negocios. Ahora nos enfrentábamos a sesiones maratonianas para estimar unos backlogs con centenares, casi mil, requerimientos. Y esta era la situación a requerimientos a alto nivel, después cada equipo dividía la parte de cada requerimiento que le aplicaba en tareas de usuario.
 
 

Como estimábamos

El proceso era tedioso, identificando primero los equipos que se necesitaban para implementar un requerimiento, después cada equipo descomponía su parte y lo estimaban a nivel equipo. Una situación muy frecuente era que un equipo no sabía si el coste de implementar una historia de usuario sería 1 o 5 o 8 puntos de historia, pues dependía de como lo implementara el otro equipo. Entonces se decidió hacer las estimaciones con representantes de todos los equipos juntos para mejorar la colaboración.
 
El siguiente reto fue la disparidad de criterios sobre cual era la historia de usuario de referencia. Necesitábamos que los equipos estimaran los tamaños de manera similar para poder tener la velocidad combinada de todos ellos. En ningún caso queríamos comparar sus velocidades, eso no tiene ningún sentido pues el objetivo era predictibilidad.
 

 
Durante semanas se condujeron sesiones entre los equipos para definir lo que era “1SP” (1 story point). Una vez todos los equipos estuvieron de acuerdo probamos una estimación conjunta. Para los que unos era 2, para otros era 8, y volvíamos a jornadas de discusiones. El resultado era añadir más complejidad al proceso de estimación, lo cual era un anti patrón. Era evidente que después de tanto tiempo invertido las estimaciones con un patrón de referencia común no funcionaban para nosotros.
 

Y apareció NoEstimates

Entonces decidimos probar la idea de NoEstimates, la descubrimos este concepto casi de casualidad y en seguida le vimos posibilidades.
 
En nuestro caso presentamos la herramienta al grupo de Product Owners y a los Scrum Masters para que nos dieran su feedback. Decidimos probar la herramienta en un entorno controlado, con unos pocos equipos, para así ver los resultados y luego actuar. La primera prueba tubo unos resultados inmejorables.
 
El concepto era sencillo. Las historias de usuario debían poderse completar por el equipo en media iteración, en 5 días laborables. Los primeros equipos que participaron en estas nuevas estimaciones acabaron con las estimaciones previstas para 2 horas en poco menos de 25 minutos. Para todo el mundo era sencillo. El tamaño era 5 días laborables y el concepto tiempo es igual para todos los equipos. Este ahorro de tiempo gustó mucho al equipo, y en seguida lo empezamos a aplicar a proyectos con más de 8 equipos. El proceso de estimar no añade valor al producto final, con lo que hay que minimizarlo a lo mínimo necesario y eso era que los equipos se sincronizaran y nos permitiera tener predictibilidad.
 
El siguiente paso, o casi en paralelo, se empezó a trabajar con los Product Owners y los Product Managers para que los requerimientos (un nivel de abstracción superior que las historias de usuario) de manera que fueran capaces de crear requerimientos que duraran la mitad de una iteración de alto nivel (6 iteraciones de equipo), de esta manera los equipos tendrían que dedicar todavía menos tiempo en estimar.
 
 

Y sobre la predictibilidad

Pasamos de tener una velocidad como resultado de puntos de historia completados por iteración a una velocidad cuyas unidades eran historias de usuario completadas por iteración. Ahora contábamos solo el numero de elementos completados, no importaba su valor, sabíamos que el tamaño máximo era media iteración.
 
Para saber cuándo terminaríamos necesitábamos contar el numero de elementos en el backlog, junto con la velocidad combinada de los equipos. La velocidad empezó a ser estable a partir de la séptima iteración, y a partir de entonces, podíamos ofrecer a nuestros clientes un nivel de predictibilidad más preciso dedicando menos tiempo al proceso de estimación.