Estimar ya no tiene sentido

“Estimar ya no tiene sentido”. Esta frase me la dijeron dos Scrum Masters antes de salir de Paradigma Digital. Fue muy curioso, la estimación es algo que está a la orden del día de todos nosotr@s. La frase ¿Cuándo va a estar? es una de nuestras favoritas, queremos dominar el tiempo y nos agobia no saber la duración de las cosas.

Sin embargo, he conocido a dos equipos Scrum que afirmaban que “estimar ya no tiene sentido”. ¡Qué curioso! Esto nos deja muchas dudas ¿A qué dedican la Sprint Planning? ¿Cómo saben cuanto entregarán? ¿El cliente está contento con el resultado?

Cultura de no estimar

Hay un poco de trampa en la frase, lo admito. Creo que la cultura “no-estimates” no es 100% aplicable en Scrum porque de alguna manera te pones un Sprint Goal, y una previsión de elementos del Product Backlog que crees que entregarás. ¡Así que sí que estimas!

El objetivo no es no estimar, sino, ¿Cómo lo haces? Los equipos más maduros utilizan datos empíricos contrastados para hacer esa estimación. ¡Un momento! Eso lo hacemos todos ¿Verdad? Todos miramos la velocidad de los Sprints anteriores para predecir el futuro.

Cuando decimos dato empírico, nos referimos a medir la cantidad de trabajo terminado en términos de PBIs por Sprints, no en términos de puntos, horas o días. El motivo de no mirar estas últimas es que se basan en estimaciones hechas con poco fundamento lo que lo convierte en métricas poco científicas.

Los puntos y el escalado con Scrum

Tuve la suerte de acompañar a un equipo que tuvo que escalar Scrum. En un momento dado eran 9 personas; fueron creciendo hasta las 17 e iban a crecer hasta las 32. Ya con 17 las Daily Scrum (que si seguimos el framework, no lo eran) eran interminables y no hablemos de las Sprint Plannings. Ellos decidieron aplicar Nexus y escalar, de manera que crearon 3 equipos multifuncionales capaces de entregar cosas y un 4º equipo de Integración (Nexus Integration Team).

En su día este equipo Scrum incorporó la técnica de estimación basada en Puntos de Historia. Trataban de estimar en equipo a nivel de User Story en vez de por tareas. El problema surge al convertirse de Scrum a escalado con Nexus porque ahora iban a ser varios equipos y claro, a la hora de planificar y generar su Sprint Backlog no iban a estar juntos. La primera estrategia por la que optaron fue la de buscar el “punto universal”, es decir, una tarea común a los equipos que les permitiera hacer la misma estimación entre cada uno de los equipos Scrum del Nexus Team.

El problema era que, si ya los puntos tienen algo de subjetivo entre Sprint y Sprint, esto se acrecentaba en un escalado. Unir puntos de diferentes equipos no funcionaba y les aportaba poca información de cara a proyectar su trabajo y hacer una previsión de trabajo completado.

A raíz de una formación que tuvimos con Jerónimo Palacios en la que nos enseñó el uso de PBIs por Sprint estuve pensando que este equipo podría ser candidato a implantarlo.  Se daban varias condiciones favorables:

• Tenían histórico.
• Eran un equipo maduro
• Tenían hambre de probar cosas nuevas.
• Tenían una Definition of Done y la cumplían, por lo que todo el trabajo estaba realmente terminado. (y si no lo estaba no se medía).
• Al compartir el Producto Owner   ayudado por personas del Nexus Integration Team que es quien genera los PBIs, es probable que estos fueran similares y eso evitaba el argumento que se usa contra esta técnica: “si los PBIs no son homogéneos entonces no se puede utilizar esta técnica “.

Hablé con varios miembros del equipo y les lancé el reto. Al principio hubo dudas, pero ellos decidieron probarlo. ¡Apareció su hambre por probar cosas nuevas!

Unos meses después ellos descubrieron que más o menos realizaban siempre la misma cantidad de PBIs. Gracias a esto pudieron eliminar la parte estimativa de la planning y les permitió hacer lo que realmente importa ¡Planificar!

Pensad que estamos hablando de 30 personas que tienen que trabajar como equipo. Los debates sobre cómo se van a organizar son más importantes que el hecho de tener números inventados para poder medir con datos poco fiables el trabajo.

Este tipo de técnicas están más relacionadas con la base de Scrum (y por tanto de Nexus también) porque se basan en empirismo. En medir de manera real el trabajo finalizado por encima de medir el trabajo estimado o la calidad de las estimaciones.

¿Y qué pasó con el otro equipo? 

El otro equipo era algo diferente, eran 5 personas y con un perfil senior todas ellas. En este caso no hizo falta que ningún Agile Coach les recomendara no estimar, lo decidieron ellos solos. En un ejercicio de autoorganización decidieron en la planning no utilizar el planning poker sino determinar en cada Sprint a dónde creían que llegarían y, al parecer, cometieron pocos errores. Es verdad que este equipo tenía unas características singulares: eran expertos, habían trabajado juntos previamente, tenían margen para el error. Lo mejor de este equipo es que fueron buscando lo que de verdad es útil para ellos. A pesar de que Scrum es muy cerrado para sus reglas, es muy amplio para decidir cómo trabajar y este equipo no vio útil estimar a la «vieja usanza» y hacerlo de otra manera. ¡No obligas a tus equipos a estimar! Scrum no obliga, sólo hazlo si es útil de verdad. 

En el futuro espero que la frase “estimar no tiene sentido” aparecerá en más equipos. No es que sea un amante del “no-estimates” pero desde luego estoy en contra del “only-estimates” a la hora de la Sprint Planning.

Cito una frase de Joel Barker que me ha inspirado «Lo que es difícil o imposible en un paradigma, es fácil o hasta trivial en otro». Por eso para equipos que van madurando en Scrum la estimación empieza a tener menos sentido.

Y tú. ¿Cuánto tiempo ocupan las estimaciones en tu Sprint Planning?