¿Quién debe priorizar el Product Backlog en Scrum?

Según la guía Scrum el Product Owner es la única persona que prioriza el Product Backlog. ¿Es siempre la manera adecuada y/o más eficiente?

Agile y Scrum nacen principalmente del mundo del Software, aunque en los últimos años se han llevado a otros ámbitos de las empresas. Scrum plantea al Product Owner como una única persona. La realidad de la empresa nos empuja a implementar algún tipo de escalado de Scrum, en el que aparecen, de una forma y otra, Product Owners de Product Owners. ¿Significa esto que se está haciendo una mala implementación de Scrum? ¿O nos estamos adaptando a las necesidades tal y como indica Agile? ¿Tiene que de verdad ser una única persona? ¿O hay otras posibilidades manteniendo la cultura Agile?

Si me lees habitualmente sabes que me gusta enfrentar la teoría a la realidad, o al menos a la realidad que yo he vivido o que mis compañeros de Enciende la Luz me cuentan. Evidentemente hay otras situaciones que desconozco para las que probablemente la propuesta que haré más adelante, no sea adecuada.

La Guía Scrum

La figura del Product Owner está muy ligada, aunque no es exclusiva, a la implementación de Scrum como framework de trabajo Agile. En su última versión, aquí puedes encontrar todas Scrum Guides, dice:

“El Propietario del Producto también es responsable de la gestión eficaz del Product Backlog.”

“El Propietario del Producto es una persona, no un comité. El Propietario del Producto puede representar las necesidades de muchas partes interesadas en el trabajo pendiente del producto. Aquellos que deseen cambiar el trabajo pendiente del producto pueden hacerlo tratando de negociar con criterio con el Product Owner.”

Abre la puerta a que el Product Owner delegue esa responsabilidad en otras personas, pero siempre será quien tenga la última palabra y responsabilidad del Product Backlog. Es muy clara en este punto, 1 Product Backlog → 1 Product Owner. Voy a quedarme aquí por el momento.

 

¿Qué dice Agile?

Agile propone un modelo de negocio que nos convertiría en una empresa que pone al cliente en el centro y genera productos que cubren sus necesidades, en lugar de tener a nuestro producto en el centro y luego vendérselo al cliente.

Agile no dice nada sobre la figura del Product Owner. Agile lo que plantea es que pongamos foco en entender la necesidades de los clientes y colaborar con ellos para adaptarnos a sus necesidades cambiantes.

“Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan”

Y si te lees los 12 principios , hay uno que para mí es muy interesante y que afecta a la figura del Product Owner en Scrum:

“Los responsables de negocio y los desarrolladores
trabajamos juntos de forma cotidiana durante todo
el proyecto.”

Es un planteamiento que surge, entre otras cosas, por la enorme distancia que existía (y aún sigue existiendo en algunos casos) entre el software y el negocio, y la falta de entendimiento entre ambos.

¿Qué ocurre en las empresas?

En los clientes en los estamos colaborando y hemos colaborado, identificamos patrones de comportamiento claramente establecidos a la hora de ampliar el radio de acción de los Product Owner de los equipos Scrum. Independientemente de dónde provenga, negocio o tecnología, su ámbito de actuación estará limitado por 2 elementos principalmente: jerarquía y conocimientos. Jerárquicamente el Product Owner forma parte de un área o departamento concreto, tiene unos responsables jerárquicos que determinan hasta dónde llega su radio de acción dentro de la empresa. A nivel de conocimientos su carrera profesional dentro de la empresa y su interés para conocer que pasa alrededor determinarán mucho cuánto conoce del negocio y del cliente.

El equipo Scrum

Un Equipo Scrum lo forman de 3 a 9 personas, entre las que se encuentra el Product Owner. En una compañía mediana o grande habrá N equipos Scrum, con N Product Owners, atendiendo a múltiples necesidades. Esto hace que para cubrir los diferentes niveles del negocio (operativo-táctico-estratégico) surja la necesidad de un escalado de Scrum, que no está descrito en la guía, y que empiece a aparecer la figura del Product Owner en diferentes niveles de la organización, con otros Product Owner por debajo supeditados al que tienen por encima. Esto no es más que cambiar una jerarquía por departamentos funcionales a una por cercanía al cliente y nivel de conocimiento del negocio. Y bueno, en una aplicación extrema nos puede llevar a que el Product Owner sea el CEO, y que en realidad todo cambie para quedarse igual que antes.

Mi visión

Sinceramente, y esto es una opinión personal totalmente cuestionable, Scrum y gran parte de los escalados basados en él no están preparados para llevar a cabo en condiciones reales algunos de los fundamentos de Agile en empresas medianas, y no digamos ya grandes corporaciones. En las empresas no hay una única persona que conozca todos los aspectos necesarios y tenga toda la información para tomar decisiones sobre las necesidades de los distintos clientes y a la vez alinearlas con las necesidades del negocio. Incluso los CEO, los directivos, y los dueños de la empresa, se apoyan en terceras personas para tener información suficiente con la que tomar decisiones. ¿Por qué centrar entonces en una única persona la responsabilidad final sobre las prioridades del producto que necesita el cliente?

¿Quién prioriza el Product Backlog?

A estas alturas te estarás preguntando, “vale, pero entonces ¿Dónde nos lleva todo esto?”. Es una propuesta sencilla que llevamos a todos los clientes, y que basándonos (entre muchos otros aspectos) en los fundamentos de Agile adapta la implementación de Scrum para cubrir de forma más adecuada las necesidades de nuestros clientes.

Filosofía Agile

Atendiendo al principio Agile sobre que negocio y desarrolladores van de la mano, planteamos que por encima de los equipos Scrum exista un espacio de decisión común entre tecnología y las áreas de negocio. Un espacio en el que se toman decisiones por consenso, y los asistentes aportan su conocimiento y capacidad de decisión para priorizar los productos y servicios que ofrece la compañía a sus clientes. De este espacio lo que obtendremos es un Backlog que combina todas esas visiones del cliente y del negocio con la tecnología, y lo prioriza mirando a lo más relevante en cada momento.

Impacto en Scrum

Desde el punto de vista de Scrum los Product Owner dejan de tener la responsabilidad total sobre la priorización del Product Backlog, ya que se ven supeditados a las decisiones tomadas en consenso. Aún así mantienen la responsabilidad de priorizar el Product Backlog de su equipo Scrum, con la parte del producto que les corresponda. A cambio ganan conocimiento sobre la empresa y amplían su visión global del negocio. Tendrán un mejor entendimiento de las decisiones tomadas por las capas superiores de la empresa, con lo que en el medio y largo plazo mejorará su desempeño como Product Owner.

¿Quieres saber más?

Si quieres profundizar en esta idea y conocer algo más sobre cómo planteamos el rol del Product Owner y su relación con la empresa, te animo a leer alguno de nuestros artículos anteriores:

Danos tu opinión

¿Es un mal Scrum o es un Scrum que se adapta? ¿Te parece más Agile? ¿Cuál es tu experiencia y que cosas has probado? Cuéntanos en los comentarios, y que podamos aprender de lo que te ha ocurrido a ti.

También te puede interesar.

El Product Owner y su relación con los Stakeholders

Como Product Owner enseguida te has dado cuenta de la gran importancia que tiene tu relación y la del Equipo Scrum con los Stakeholders.

Ventajas de aplicar el Lead Time en los Equipos Scrum

En ocasiones, cuando arrancamos con los Equipos Scrum, nos encontramos con un par problemas habituales: el tamaño de los PBIs y que trabajan en paralelo en todas los PBIs del sprint. Hoy te traigo una solución que hemos puesto en marcha en algunos Equipos Scrum de nuestros clientes.

Cómo mejorar tu Scrum Daily

En ocasiones nos encontramos con equipos en los que la Scrum Daily se ha convertido en un evento individualista donde cada miembro del equipo de desarrollo comenta las tareas realizadas durante el día anterior, muchas veces con cierto carácter de reporte. Sin embargo, la daily es un evento colectivo donde a través de la inspección y adaptación se traza un plan de trabajo del día para el equipo.

Las consecuencias de un Backlog interminable

Nuestro Product Backlog con el tiempo se va llenando y convirtiendo en un Backlog interminable. En este artículo te planteo las consecuencias más relevantes que tiene.

Burndown y Burnup para el Scrum Master

Como Scrum Master puedes obtener información muy valiosa analizando estos dos gráficos para entender lo que está ocurriendo en tu equipo.

Es importante usar Historias de Usuario

Usar Historias de Usuario es importante para los Product Owner, además de la más utilizada a la hora de escribir el Product Backlog.

Scrum ayuda a la mejora de la calidad en los productos

Scrum es simple e incompleto, solo define las partes necesarias para implementar la teoría de Scrum, permitiendo a las personas que lo utilizan generar sus propias instrucciones para conseguir alcanzar sus metas y crear valor. Y ahí está la dificultad para aprender a usarlo y mejorar la calidad de nuestros productos.

Monta equipos Scrum de éxito

Cómo montar equipos Scrum de éxitoYa sabes lo que es un equipo Scrum. Es hora de dar un paso adelante y entender cómo montar un equipo Scrum de éxito. ¿Qué tipo de perfiles incorporas? ¿Cómo se balancean? ¿Cuándo les incorporas? Son preguntas que probablemente te...

Sprint Review: más allá de la demo

La Sprint Review es el evento de Scrum donde se muestra el resultado del sprint. Una buena review te ayudará en la estrategia de producto.

Entender a los Equipos Scrum desde las Métricas

En nuestro trabajo diario con los equipos Scrum, es importante entender qué está ocurriendo sprint a sprint, y en qué lugares debemos poner el foco de las acciones de mejora de los equipos. También es importante disponer de datos objetivos, que en las sesiones de retrospectiva o de revisión del proceso, nos ayuden a tomar decisiones basadas en la realidad, y no en sensaciones u opiniones subjetivas.

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Aceptarás nuestra política de cookies si continúas navegando.

ACEPTAR
Aviso de cookies