La planificación, ese evento al que le damos una importancia vital sobretodo en el mundo tradicional. En Scrum puede tener importancia, pero quizás un buen Scrum le da más importancia a la Sprint Review porque es donde analizas el mercado.
Aún así, las planificaciones son importantes, es el momento donde nos organizamos, donde nos marcamos objetivos y donde preparamos el Sprint que tenemos por delante. A mi me gusta dividir la Sprint Planning en tres partes diferentes: ¿Qué vamos a hacer? ¿Cómo lo vamos a hacer? y el Acuerdo final.
En este artículo vamos a centrarnos en “¿Qué vamos a hacer?”. En esta parte, el Product Owner trae los elementos del Product Backlog que le gustaría que se hicieran y acuerda junto con el Development Team el Sprint Goal. Esta parte se puede volver infernalmente larga si no la tenemos bien preparada por eso es esencial (que no obligatorio) el Refinamiento.
Al Product Owner le cuesta tomar decisiones
Recientemente estuve colaborando con un equipo y me transmitían que al Product Owner le costaba tomar decisiones. He vivido en mis propias carnes esta situación y quería dar algún consejo o apunte. Siempre decimos que los dos principales fallos de un Product Owner es es que o no tiene tiempo, o no tiene poder. Cuando lo segundo ocurre, lo que acaba pasando es que en las Sprint Plannings se divaga mucho, porque al no tener poder, todo hay que consultarlo y eso hace que empecemos Sprint sin que las cosas estén claras. Sabemos que el software es cambiante, pero si ya partimos de requisitos mal definidos complicamos mucho las expectativas. Además, complicamos el que el Product Owner gane confianza que le permita adquirir “poder de decisión”.
Tomar una mala decisión por empezar rápido puede llevarte a perder confianza que te impida en el futuro tomar mejores decisiones.
Gestionar expectativas como Product Owner
Tuve la pequeña experiencia de durante seis semanas ser Product Owner en un gran banco, en el que trabajé con Managers que podrían “fulminarme” al ser una persona externa a la organización. ¿Cómo consigues hacer tu trabajo? En mi caso, creamos una mini reunión de 15 minutos cada dos días que utilizábamos para gestionar el backlog y las expectativas. Nos reuníamos con todos los managers y yo hacía de facilitador de la sesión para conseguir que la prioridad fuera consensuada. No se trata de ser el rey del backlog, se trata de aportar el máximo valor apoyándote en la organización que das servicio. ¡Es la mejor arma para un Product Owner sin poder!
Otra táctica que se puede dar es utilizar Sprints cortos, 1-2 semanas. De esta manera, las decisiones del Product Owner son de menos calado y así puede tomar decisiones más rápido.
Acompañando al Product Owner
Un papel fundamental aquí lo juegan los Scrum Masters. Cuando tu Product Owner le cuesta decidir, es importante enseñarles a hacer refinamientos y enseñarle la importancia de que hay que actualizar el Product Backlog constantemente porque constantemente vamos al mercado y aprendemos.
A la hora de cómo organizar el refinamiento, recordemos que Scrum dice que es labor del Product Owner, sin embargo, puede utilizar un 10% del tiempo del Development Team para ayudarle. En un equipo en el que estuve, primero tratamos de que el Scrum Master (que era yo) se encargará de ayudar al Product Owner. Dado que a nivel funcional era bastante nuevo, mi asesoramiento era poco útil como vimos en la siguiente Sprint Planning. Después probamos a que el propio equipo entero se reuniera con el Product Owner, esto ayudaba, pero realmente lo que hacíamos era adelantar la Planning y encima quitamos el foco del Sprint Goal ¡No podemos ir en contra de nuestros valores! La siguiente decisión fue que al terminar la Restrospectiva todo el Development Team miraría el Product Backlog para preparar dudas; ahí aprendimos que era demasiado tarde y que eso no ayuda.
¿Cuál fue la decisión final?
Decidimos tomar la siguiente estrategia. La primera semana del Sprint el Product Owner tenía que tener todo listo como si el Sprint fuera a empezar. La segunda semana, el compañero del Development Team que más conocimiento funcional tenía lo revisaba y se sentaba con la Product Owner para revisar lo que se podía o no hacer y si tenía dudas preguntaba a los compañeros. ¡Por fin! Esto ya nos funcionó durante mucho tiempo porque permitió tener los requisitos claros.
Definition of Ready como herramienta
La última recomendación que puedo hacer es trabajar la Definition of Ready. Actualmente la Guía Scrum no lo incluye y al parecer está generando un debate en la comunidad. De hecho, Jeff Sutherland (co-creador de Scrum) sí que habla de ella. La Definition of Ready (DoR) es un conjunto de reglas que deben cumplir los elementos del Product Backlog para que se puedan acometer en un Sprint. Definir estas reglas en el Scrum Team es esencial, y que se revisen en las Retrospectivas también. Por ejemplo, nos pasó una vez que nuestro Product Owner quiso que hiciéramos una pantalla con una dirección y no quedaba claro si quería varios campos o uno grande. El debate acabó con un “tengo que consultarlo”. Debido a eso, pusimos una regla “cualquier pantalla que queramos hacer debe estar prototipada”. ¡Ganamos todos! El Product Owner ya sabía que tenía que hacer para que no volviera a ocurrir y el Development Team pudo tener las cosas más claras.
Un consejo respecto a la Definition of Ready es que, si un elemento del Product Backlog no lo cumple antes de la Sprint Planning ¡No debería pasar nada! Durante la Sprint Planning se debería poder clarificar para que lo cumpliera y por tanto entrar en el Sprint. Comento esto, porque la Sprint Planning también se puede utilizar para clarificar elementos poco claros. De hecho, las Historias de Usuario mejores son las que son negociables, y eso es bueno porque permite dar una mejor solución tras un debate.
Preparar bien la Sprint Planning requiere disciplina y trabajar duro durante el Sprint. Un buen Product Owner no se relaja tras una Sprint Planning, ya está pensando en la siguiente. Apoyarse en el mercado, hacer frecuente inspección & adaptación y utilizar la retrospectiva como palanca de mejora nos ayudará a encontrar nuestra Sprint Planning perfecta. Si tu Sprint Planning es muy pesada, no te rindas, busca tu camino y trata de solucionarlo.
