Sin duda alguna el mayor reto a la hora de enfrentarnos a una estimación es cuando la historia de usuario implica a varios stacks tecnológicos. Hoy en día es muy habitual encontrarse esta situación, como anécdota, yo he llegado a ver equipos con hasta 4 stacks tecnológicos distintos enfrentarse a esta situación.
La gran mayoría de las aproximaciones, que he visto utilizar a los equipos, pueden agruparse en dos casos tipo: las que estiman en conjunto el equipo, o bien las que no todo el equipo estima las historias.
Caso 1: El equipo no estima conjuntamente
Dentro de este grupo he visto equipos en los que varios miembros se inhibían de estimar por desconocer la tecnología. Otros, se separaban en sub-equipos por stack tecnológico para estimar, y sumaban el total de las estimaciones en la historia. Y he visto incluso, como se dividían directamente las historias por tecnología, teniendo incluso su propio Kanban por Stack tecnológico.
En todos los casos lo que más preocupaba a los equipos era la precisión a la hora de estimar cuándo la preocupación debería centrarse en entender mejor lo que se estima. Y en todos los casos tan sólo estimaban unos pocos miembros del equipo cada historia.
PROS
- Las estimaciones son más precisas, con lo que a priori, el Product Owner podría inferir con mayor certeza en que rango de fechas podría liberar una release.
CONTRAS
- Al dividirse en sub-equipos por stack tecnológico, pueden aparecer silos de comunicación.
- La implicación del equipo en acabar la historia se transforma en la implicación del sub-equipo en acabar su parte.
- Puede generar malos rollos en el equipo.
NOTA: Recuerda que en la guía Scrum pone literalmente:
Scrum no reconoce títulos para los miembros de un Equipo de Desarrollo, todos son Desarrolladores, independientemente del trabajo que realice cada persona; no hay excepciones a esta regla.
Guía Scrum. Por Ken Schwaber y Jeff Sutherland
Caso 2: El equipo estima conjuntamente
Por otro lado están quienes optaron por seguir estimando conjuntamente, independientemente de los stacks tecnológicos que requiera la Historia de Usuario. He de decir que esta aproximación es un poco más compleja al inicio, pero también es la mejor que conozco y la que mejores resultados ha dado a los equipos.
Hay que estimar las historias de usuario en equipo, y es cierto que habrá quién no podrá/sabrá estimar algo fuera de su dominio tecnológico, ¿cómo sorteamos esto?
Bueno, simplemente hablando y escuchando al equipo, entendiendo cómo de compleja es cada parte explicada por quien mejor la conoce, y votar en consonancia. De tal modo que podamos comentar:
“Oye para mí esta nueva historia es un 3 porque se parece mucho a la página de login que hicimos”
Mientras que otro miembro que domine frontend puede puntualizar:
“Pues yo creo que es un 5, debido a que hay que realizar más trabajo en front que el que hicimos en la página de login”
De este modo, el equipo completo conoce mejor a qué se enfrenta, y afrontará el desarrollo como equipo.
PROS
- Aumenta la implicación (engagement) y el compromiso (commitment) del equipo que son dos de los valores que promueve Scrum
- Se llega a un entendimiento más completo de la historia a pesar (tallar, estimar).
- Se facilita la colaboración entre los miembros del equipo al entender en que modo cada individuo contribuye al todo.
CONTRAS
- Es un poco más complejo de entender, aunque es sorprendentemente simple una vez que se entiende.
- Al ser más difícil de entender puedes tener cierta reticencia por parte del Product Owner que pueda dudar de la precisión de la estimación. Pero recuerda, el equipo es soberano a la hora de estimar, aunque la estimación tiene que tener en cuenta toda la información, posibles riesgos y dudas que haya trasladado el Product Owner.
