¡Nuevo episodio de Scrum Manager Podcast! También disponible en Spotify e iVoox.
En episodios anteriores hablamos de la serie Fibonacci y la estimación. Hoy queremos explicar otras formas de estimar… y de no estimar.
Recordad que las transcripciones de todos los episodios estarán disponibles en el blog, e iremos subiendo a ritmo de sprint: cada par de semanas. ¡No dudéis en sugerirnos temas sobre los que os gustaría profundizar en los comentarios!
Transcripción
¡Hola y bienvenidos! En este episodio seguimos donde lo dejamos al principio de temporada con la serie Fibonacci: veremos otras formas de estimar… y de no estimar.
La estimación de tareas es una práctica común en los proyectos ágiles, pero también puede ser una fuente de debate y desacuerdo. Algunos equipos consideran que es esencial para una buena planificación y cumplir con los objetivos del proyecto, mientras que otros lo ven innecesario, o incluso perjudicial.
Vamos a explorar estas diferentes perspectivas y a discutir cómo los equipos pueden encontrar el enfoque que mejor se adapte a sus necesidades.
Técnicas de estimación
Aunque el planning poker, sobre todo combinado con la serie Fibonacci, es una de las prácticas de estimación más populares, no es la única. Ya explicamos que la clave por la que la serie Fibonacci es más útil que una serie de números consecutivos normal es que permite comparar y estimar de forma relativa unas cifras con otras.
Tallas de camistas
Siguiendo un poco la misma idea, existe otra técnica que estima tareas usando tallas de camiseta: S, M, L, XL… Igual que con la serie Fibonacci, ante la duda es preferible estimar al alza. Y si una historia es demasiado grande (XL, XXL…) eso significa que habrá que descomponerla en otras menores. Es una técnica muy informal y en la que el equipo, como en planning poker, vota y comenta en voz alta para consensuar las decisiones. A veces se asignan valores numéricos a las tallas después de estimar. Para «traducirlas» a puntos de historia.
Bucket system
Otra técnica muy diferente es el Bucket System, que se recomienda para estimar un gran número de historias. Con «gran número» queremos decir que un backlog entero se puede estimar con esta técnica, porque es muy rápida y divide el trabajo entre el equipo en lugar de consensuar en voz alta estimación por estimación. Vamos a explicar paso a paso cómo se hace:
- Primero hay que preparar tarjetas con valores del 0 hasta uno muy alto. 100, 200, o incluso 500. No hay que colocar todos los números intermedios, se puede usar por ejemplo la escala Fibonacci hasta el 89 y luego 100, 200, 500. - Necesitaremos tener las historias escritas en tarjetas también. Todo esto por supuesto puede ser físico o en formato digital. - Con las historias y los valores listos, empezamos: un miembro del equipo elige una historia al azar, la lee en voz alta y la coloca, sea cual sea, en el valor 8. Luego se lee una segunda historia, al azar. Si la primera historia era un 8, se decide en consecuencia el tamaño que debería tener esta segunda en relación. Y se hace lo mismo con una tercera historia. Con estos tres elementos podemos empezar a intuir si nuestra escala está muy desviada. Por ejemplo, puede que la primera tarea fuera realmente pequeña y la tengamos que mover al valor 1. Ajustamos.
Y a partir de aquí, se dividen las demás historias entre los miembros del equipo para que las coloquen en el valor que consideren más adecuado. El mismo valor puede contener muchas historias, de modo que las de tamaño similar quedan agrupadas.
Se trabaja individualmente, no hay que dar explicaciones a los demás. Los ajustes se dejan para el final. Si alguien recibe una historia de un área que no controla, se la puede pasar a un compañero para que la estime en su lugar.
El resultado final se revisa en grupo, y se debate si alguna historia está en un valor poco realista. Por último, en la tarjeta con cada número, se apunta cuántas historias de ese tamaño hay.
«Grande, incierto y pequeño»
¿Suena tedioso? Hay un par de técnicas similares aún más sencillas, también recomendadas para cuando hay muchas historias que estimar. La primera es «grande, incierto, pequeño». Sigue la misma dinámica que el bucket system pero utilizando sólo esos 3 valores.
TFB, NFC, 1 sprint
Y para ser aún más informales está la técnica TFB, NFC, 1 sprint. Que quiere decir too fucking big «demasiado grande», no fucking clue «ni idea» y un sprint. Misma dinámica. Y, como el nombre indica, las tareas se dividen entre:
- Las que caben dentro de 1 sprint, porque costarán eso o menos.
- Las que son demasiado grandes para un sprint, así que habrá que analizarlas y dividirlas.
- Y las inciertas.
El nombre de la técnica es muy informal, pero no podemos negar que son tres grupos con propósitos clarísimos. Y si es útil, es útil.
Affinity Mapping
Luego está el Affinity Mapping, o «mapeo por afinidad». Consiste en agrupar historias de dimensión similar, sin usar otros valores más allá de las historias en sí. Se recomienda para grupos no demasiado grandes de historias, entre 20 y 50.
Hay mucho donde elegir. No sólo hay más técnicas aparte de éstas, sino que es habitual usar combinaciones. Por ejemplo, el planning poker como tal no tiene por qué usar la secuencia Fibonacci, pero es un buen combo. Las tallas de camiseta pueden hacerse seguidas de un affinity mapping. Y aunque votar con puntos de colores o dot voting es algo que suele usarse para priorizar y no para estimar, hay coaches que adaptan esta técnica, de forma que cuantos más puntos recibe una historia más grande es.
#Noestimates
Pero es que además hay equipos que reniegan de las estimaciones por completo y que no estiman, y tenemos que hablar de esto. El movimiento #NoEstimates viene del desarrollo ágil, y el hashtag fue acuñado por primera vez por el consultor Woody Zuill en 2012. Y desde entonces ha ido ganando tracción.
Algunas críticas habituales en contra de las estimaciones son:
- Que consume tiempo, sobre todo en proyectos grandes. Y que es mejor invertir ese tiempo trabajando, en vez de hablar sobre el trabajo.
- Que las estimaciones son siempre inciertas e imprecisas, y fingir que no lo son lleva a retrasos, malas decisiones o tareas mal priorizadas.
- Que prestar demasiada atención a las estimaciones puede llevar a una planificación poco flexible en el proyecto, y es mejor centrarse en responder e ir adaptando el plan continuamente.
- Y que estimar no siempre es necesario, sobre todo en proyectos o equipos reducidos. Puede ser más fácil avanzar sin estimaciones formales.
Por supuesto, estas críticas se pueden contra-argumentar, y estimar o no estimar puede tener más o menos sentido según el contexto. Pero los equipos que no estiman existen. Es posible mantener un flujo continuo de trabajo sin estimar tareas, tanto en equipos que usan timeboxing, como hace scrum, como en equipos que usan kanban. No quiere decir que no descompongan las tareas grandes en otras más pequeñas; lo que no hacen es estimar su tamaño siguiendo una técnica formal.
Puede ser apropiado en proyectos con un alto grado de incertidumbre, o cuando se trabaja con muchas tareas pequeñas y de poca complejidad. En este último caso también se usa capacity-based planning, que estima en base a la disponibilidad y capacidad de trabajo del equipo con los recursos disponibles, sin estimar el tamaño de las tareas por lo dicho, porque suelen ser pequeñas y sencillas. El equipo intenta prever si acaso el volumen de tareas, si puede que la demanda aumente durante un periodo de tiempo por algún gran evento por ejemplo, y se centra en completar todas las que pueda durante el sprint.
Entonces, ¿cómo podemos encontrar el sistema que mejor se adapte a las necesidades de nuestro equipo o proyecto? Veámoslo.
Puede que tengamos que probar varias técnicas hasta dar con el sistema de estimación que más ayude a nuestro equipo. Tenemos que ser conscientes de nuestro contexto y nuestras necesidades.
- En primer lugar, ¿cuánta experiencia tiene el equipo? y ¿qué opinión tiene cada quién sobre las estimaciones? A lo mejor ya estamos acostumbrados a trabajar con un método específico, o hay muchas personas en el equipo que preferirían no estimar, por ejemplo.
- Pero también hay que considerar las necesidades del proyecto y del cliente: el nivel de complejidad de las historias, los plazos, presupuesto, cuál es el grado de rigidez o flexibilidad, cuál es la relación con el cliente, y si éste necesita que estimemos.
En función de estos factores, o si éstos cambian, puede que sea buena idea experimentar y adaptar nuestra manera de estimar o no estimar.
¿Deberíamos estimar o no?
Tal vez esa sea la primera pregunta: ¿deberíamos estimar o no?
¿Qué ventajas e inconvenientes ofrece cada alternativa? Vamos a verlas en general, para tenerlas en cuenta y decidir qué opción puede dar mejor respuesta según el contexto.
Estimar puede dar una idea más clara de la carga de trabajo y el tiempo necesario para completar las tareas del proyecto, aunque nunca seamos exactos. También puede ayudar a identificar posibles riesgos y obstáculos, al hacernos más conscientes de lo que queda por completar. Pero puede llevar más tiempo, sobre todo si el equipo tiene poca experiencia. Y una mala estimación puede llevar a una mala planificación y a fallar en el cumplimiento de plazos. Puede darnos una sensación de falsa seguridad, sobre todo si estamos haciendo planes a largo plazo en base a estimaciones.
Por otro lado, si decidimos no estimar, eso puede ayudar al equipo a centrarse en la entrega de valor y la colaboración constante y directa. Es decir, que el product owner y el equipo ven día a día qué tal avanzan las historias en curso mediante las herramientas o eventos dispuestos para ello, sin depender de una estimación previa. Quienes están a favor de este enfoque argumentan que se ahorra tiempo y costes también, aunque se puede argumentar que las técnicas de estimación ágil se centran en ser rápidas y resolver las discrepancias lo antes posible y sin discutir. Por otro lado, no estimar puede hacer que las partes interesadas en el proyecto sientan incertidumbre sobre el plan de avance.
Y esto nos lleva a una situación muy habitual: que el cliente prefiera que se estime, y el equipo que no. Por un lado, el cliente busca controlar mejor el avance del proyecto y planificar presupuestos. Por otro lado, el equipo puede tener una actitud indiferente o escéptica ante las estimaciones. Pueden argumentar que preferirían no perder ese tiempo en las reuniones, no generar falsas expectativas, y no entrar en dinámicas de planificación excesiva que pueden dañar la agilidad y flexibilidad del proyecto.
En estos casos, la decisión de proporcionar estimaciones o no es una cuestión de negociación y encontrar un equilibrio entre lo que todos los involucrados necesitan. A veces, el cliente necesitará estimaciones, pero dependiendo de para qué se pueden plantear alternativas.
Si decidimos estimar
Si decidimos que vamos a estimar, aún queda la pregunta de qué técnica usar. Vamos a dar algunas recomendaciones generales.
Primero, consideremos el grado de experiencia del equipo y si queremos aprovechar para alinear la visión de todos con estas dinámicas. Si el equipo tiene poca experiencia, el planning poker con escala Fibonacci puede ser una buena opción.
Las técnicas que requieren hablar y consensuar las decisiones brevemente como ésta, o las tallas de camiseta o agrupar tareas afines (affinity mapping), ayudan a trabajar la visión compartida del equipo y la empatía entre sus miembros.
Otro aspecto a considerar es el volumen de tareas que tenemos que estimar. Si son muchas tareas y buscamos una estrategia rápida, podemos usar el bucket system, o separar entre «demasiado grande, ni idea, 1 sprint».
Y por último dependemos de si alguien, nosotros o el cliente, necesita puntos de historia. Hay técnicas que usan cifras concretas, como el planning poker o el bucket system, y técnicas que no, como «grande, incierto, pequeño».
Esperamos que estos consejos os ayuden a valorar las ventajas y desventajas de cada opción y a tomar una decisión informada. En la transcripción del podcast de nuestro blog encontraréis enlaces a técnicas concretas para estudiar las que más os interesen con más detalle.
Volveremos con el próximo episodio en lo que se tarda en hacer un sprint: un par de semanas. Hasta entonces podéis encontrarnos en Twitter, LinkedIn, y en scrummanager.com.
¡Mucha suerte con vuestro proyectos y hasta la próxima!