¡Seguramente a muchos Product Owner nos ha pasado!, llegamos a una organización nueva, integramos un equipo que ya tiene un Product Backlog que han venido gestionando y el Product Owner que vamos a remplazar nos entrega en 1 día o menos. Hoy quiero contarle unas buenas prácticas que desde la experiencia me fueron útiles y con certeza podrían servirle a usted.

La Guía Scrum nos habla del Product Backlog como “El trabajo pendiente del producto es una lista emergente y ordenada de lo que se necesita para mejorar el producto. Es la única fuente de trabajo emprendida por el equipo Scrum.”, por lo cual es lo primero que queremos entender y escudriñar al momento de iniciar nuestro rol de PO, sin embargo algo aún más importante de conocer y que ayuda realmente a entender el Product Backlog, es el producto, ese producto que se va a mejorar con todos los PBIs que tiene el Product Backlog.

Dicho lo anterior, una primera buena práctica es empezar conociendo funcionalmente el producto y los clientes que lo usan, para esto podemos apoyarnos con el PO que vamos a remplazar, el QA que ha probado todo lo que ya está en producción o el Product Manager según la organización en la que se encuentre o la forma en que el equipo está estructurado.

Una vez ya conocemos funcionalmente el producto, lo entendemos, nos podemos y sabemos mover en él y además sabemos quiénes son los clientes finales, podemos hacer uso de la segunda buena práctica que puedo recomendar y es establecer el método de priorización que más le funcione o que conozca teniendo en cuenta algunos factores como:

• Ingresos que trae para la compañía.
• Compromisos de un RoadMap ya establecido (si ya existe).
• Valor para el cliente final.
• Esfuerzo
• Tiempo, etc.

Una vez se establezca el método de priorización ya podemos empezar a escudriñar el Product Backlog, aquí se puede hacer de dos maneras:

1. Reunirse preferiblemente con el Líder Técnico del producto a revisar ordenadamente los PBIs del Product Backlog y luego en las sesiones de refinamiento con el equipo los vamos desglosando uno a uno.

2. Entenderlos con todo el equipo en las sesiones de refinamiento, esta segunda opción en lo que a mí respecta me funciono mucho mejor debido a que el equipo me ayudo a resolver dudas gracias a que ellos ya conocen el producto y refinábamos los PBIs en un detalle que lo entendería cualquier integrante del equipo, está práctica nos puede llevar a sesiones de refinamiento largas o a pocos PBIs refinados en una sesión, sin embargo a medida que vamos conociendo el producto y los PBIs, las sesiones pueden fluir mucho más o puede llegar al caso en que se pueda revisar previamente y llegar a los refinamientos más preparados para evitar que se prolonguen más de lo adecuado.

Ahora bien, se preguntarán ¿En qué momento usé el método de priorización? que en la segunda buena práctica se mencionó que establecieran antes.

La respuesta es que, a medida que van refinando o entendiendo PBI por PBI van priorizando según el método o criterio establecido. Por ejemplo, si establecen el método MoSCoW (Must, Should, Could, Won’t) bajo el criterio de ingresos que puede traer a la compañía, a medida que van entendiendo cada PBI del Product Backlog lo van a poder priorizar según los ingresos que esa mejora pueda traer a la compañía, y esto también les va servir para tener una sesión de planning un poco más dinámica y organizada, ya que como dice la guía Scrum del Sprint Planning “inicia el Sprint estableciendo el trabajo que se realizará para el mismo. Este plan resultante es creado por el trabajo colaborativo de todo el equipo de Scrum”.

Si la lectura le trajo hasta este punto, es hora de seguir en el camino de aprendizaje. Recomiendo conocer en detalle la Guía Scrum, y capacitarse para conocer de la mano de expertos, cómo aplicar correctamente Scrum en las organizaciones. Estos son nuestros programas de formación.

¡Éxitos!