Índice
1. Introducción
Desde que me dedico a dar apoyo a organizaciones y equipos de desarrollo en procesos de transformación ágil, he tenido la oportunidad de facilitar y participar en muchas sesiones de Scrum. En el evento de Sprint Planning me he encontrado una y otra vez con la misma pregunta cuando llega el momento de realizar estimaciones relativas:
¿Cómo puedo estimar el esfuerzo que implica hacer toda una funcionalidad si solo sé cómo hacer una parte de la misma? Desconozco lo que hay que hacer en otras partes, por lo tanto solo puedo estimar mi parte.
Siempre que pensamos en sesiones de estimación relativa imaginamos a todos los miembros del equipo aplicando planning poker, estimando el esfuerzo de una funcionalidad de forma amena y colaborativa, independientemente de la experiencia técnica de cada uno.
Pero la realidad es que esto ocurre en muy pocas ocasiones, y es comprensible: el desarrollo de una funcionalidad implica tareas de diversas áreas (UI, UX, front, back, BBDD, etc.). Pretender que todos estimen todo es casi como esperar que todos sean full stack, algo irreal.
Entonces:
- ¿Cómo se estima en la vida real?
- ¿Todos estiman todo aunque no sea su terreno?
- ¿Cada uno estima lo suyo y se suma todo para obtener la estimación global?
En este artículo quiero desenmarañar esta disyuntiva y, más importante aún, explicar cómo deberíamos abordar esta dificultad para conseguir verdaderos equipos Scrum.
2. Qué es un equipo Scrum
Según la guía de Scrum, un equipo Scrum es autoorganizado y multifuncional, es decir, posee todas las competencias necesarias para llevar a cabo el trabajo sin depender de personas externas al equipo.
Aquí conviene aclarar una interpretación errónea bastante extendida:
multifuncional no significa que cada persona sabe hacerlo todo, sino que el equipo, sumando las habilidades de todos sus miembros, tiene todas las competencias necesarias para completar el trabajo sin depender (o dependiendo lo mínimo) de otras áreas o departamentos.
3. Si el framework promueve la multidisciplinariedad… ¿por qué las estimaciones buscan valores globales?
Porque el hecho de que Scrum prescriba equipos multifuncionales no implica fomentar el trabajo por silos. Es realista respecto a:
- Cómo somos las personas y los equipos.
- El poder del trabajo en conjunto.
- El aumento de productividad cuando colaboramos.
Por otro lado, una estimación es eso: una valoración, no un compromiso escrito en piedra. Estimar —sea en días o en puntos— es solo una excusa para fomentar lo más valioso del proceso:
4. La conversación
Sí, la conversación es lo verdaderamente importante. Mucho más que el número final. Gracias a ella:
-
Detectamos tareas ocultas y posibles obstáculos.
La estimación es una de las primeras oportunidades para identificar riesgos antes de que se conviertan en impedimentos. -
Logramos una visión compartida.
Si todos entienden las implicaciones de desarrollar una funcionalidad, es más fácil comprometerse con un plan que cuando las estimaciones vienen “impuestas”.
5. ¿Quién debería estimar?
Lo ideal es que todos estimen el esfuerzo de una funcionalidad, porque esto promueve:
- Sentimiento de equipo, entendiendo que el trabajo y la responsabilidad son compartidos.
- Desarrollo del conocimiento en T, donde cada persona conoce un poco de todo y se especializa en un área.
- Reducción del bus factor, permitiendo que el desarrollo continúe aunque falte alguien del equipo.
6. ¿Cómo conseguirlo?
Con mucha conversación, colaboración, práctica y con personas que vivan los cinco valores de Scrum: compromiso, coraje, foco, apertura y respeto.
Cada equipo es un mundo, por lo que no existe una fórmula única. Pero, partiendo del principio de que se realizan estimaciones relativas (comparando con una historia base ya conocida), propongo dos estrategias:
6.1. Hacer las cosas bien desde el principio
Explicar clara y sólidamente por qué todos deben estimar todo el esfuerzo.
La experiencia puede ser abrumadora al inicio, pero con el tiempo —y tras muchas conversaciones sobre el trabajo de los demás— las estimaciones se vuelven más realistas.
6.2. Un paso intermedio
Permitir la subdivisión de una funcionalidad en sub-tareas técnicas y estimarlas por separado, incentivando el intercambio de conocimientos:
- En las conversaciones sobre una tarea de front, los de back escuchan y comprenden a grandes rasgos el trabajo y viceversa.
- Técnica adicional
- Para una tarea de front, pedir a los back que describan lo que creen que implica.
- Luego los front confirman o ajustan esa valoración.
- Repetir a la inversa para tareas de back.
El objetivo es reducir el desconocimiento sobre el área del compañero.
Después de varias sesiones trabajando así, se puede pasar al modelo de estimaciones a nivel de funcionalidades completas, facilitando una evolución natural hacia el modelo ideal.
7. Conclusión
Al principio, los equipos suelen ser poco maduros y muy especializados, por lo que es normal encontrarse con esta duda. Pero como promotores del cambio, es nuestro trabajo impulsar una transformación cultural que permita ver el trabajo como una unidad compartida.
Aunque no todos sepan de todo a bajo nivel, sí pueden comprender lo suficiente como para estimar el esfuerzo conjunto requerido para entregar valor.
- ¿Qué opinas tú?
- ¿Has vivido esta situación?
- ¿Tienes alguna técnica adicional para compartir?
Un comentario
Hola,
Me gusta lo que has dicho, también empezar a estimar, les hace pensar en si puedo hacerlo o no, porque cuando una HU, Task etc… no puedo estimarla es porque no tengo claro que hay que hacer en ella. Trabajar en periodos cortos de tiempo, has de ser consciente de si puedes comprometerte a hacerla en ese periodo de tiempo o no, y puntuar es una forma de medir ese compromiso. Al principio será prueba y error, pero luego, se darán cuenta que, que una HU de 13 en un sprint corto es un riesgo meterla en sprints pequeños y quizás tengo que trocearla.
Pero si el dialogo y hablar es básico porque puntuar una HU no es compromiso de uno es compromiso de todos y todos tienen que cumplir el objetivo, e incumplir el objetivo es algo que hacen todos. Por eso al puntuar la dificultad de una HU debe hacerse por parte de todos, porque todos se comprometen en alcanzarlo.
En principio las HU no deberían asignarse por el SM o PO a nadie, si no que el equipo se debería encarga de ello, e ir administrando el trabajo para sacarlo a delante, según se terminan las HU que cumplen un DOD, porque el fracaso o éxito del incremento es debido al trabajo del equipo, de la inspección y adaptación que se realiza durante las diales.