Tales from the Scrum: el Product Owner y el Product Backlog

Quisiera hoy detenerme en uno de los roles de Scrum: el Product Owner  (podría traducirlo por “dueño del producto”, pero voy a seguir la costumbre de usar la denominación en inglés), y en particular, en una de sus actividades.

La principal actividad, que le compete completamente, es el mantenimiento de los items del Product Backlog, y sus prioridades. Recordemos que el Product Backlog es el documento que lista la funcionalidad que esperamos del producto terminado. Esta lista es evidentemente importante: mal armada, puede hacer que el producto a entregar no sea el que el cliente final necesita.

Esa lista no la decide el Equipo, y menos el Scrum Master. Lo decide el cliente, en reuniones anteriores al inicio del proceso, donde pueden intervenir distintos interesados, pero de ahí en más es el Product Owner el responsable de mantenerlo (un Product Backlog puede cambiar con el tiempo, no es un documento escrito en piedra). Este es el responsable de entender, mantener, y conocer las prioridades de esta lista, del que saldrá el producto que entregaremos al final del proceso.

Es común, si no se conoce Scrum, querer priorizar los items por su orden “lógico” de desarrollo. No: la idea es priorizar por importancia para el negocio, para lo que necesita el cliente. De ahí que las prioridades no las decide el Equipo, sino el Product Owner.

Esto implica que la persona que encarne ese rol, debe conocer del negocio del cliente. Debe tener contacto con los principales actores de la actividad del negocio, entenderlo, y debe conocer cuáles son las áreas importantes. Demos un ejemplo.

Si tenemos que desarrollar un sistema de seguros en línea, el Product Owner deberá decidir qué partes del sistema a entregar darán más valor al negocio, y por qué. Tal vez, el grueso del negocio sean los seguros de vida, o tal vez el seguro de camiones, o quizás el seguro de autos. Dependiendo de ese dato, se podrá priorizar el tener una aplicación para calcular un seguro de vida, antes que uno de autos. No se comienza por lo “más fácil”, o por “lo que nos están pidiendo ahora”, sino por lo más importante.

Si un equipo técnico tuviera que decidir sobre esos puntos, seguramente tomaría primero el tener una base de datos, o un sistema de seguridad, o cualquier otro punto. No es la idea en Scrum: la idea es entregar, al final de cada Sprint, iteración, algo que agregue valor. Por supuesto, lo entregado deberá cumplir con la calidad esperada por el cliente, pero debe estar alineado con los items del Product Backlog, armado y priorizado por el Product Owner.

Como escribía más arriba, el Product Backlog inicial no es necesariamente EL Product Backlog final. Pero los cambios, de items, de prioridades, deben ser hechos por el Product Owner. El Equipo podrá levantar la mano, sugerir cambios, pero la decisión de cualquier modificación, recae en el Product Owner. Y éste no deberá cambiar los items por cualquier causa: deberá consultar con los interesados en el proyecto, con los que conocen del negocio, y estar atento a cualquier cambio en el entorno, para poder priorizar los items que son necesarios mantener en el Product Backlog.

Vean entonces, la importancia del rol del Product Owner. De hecho, hay cursos especiales de entrenamiento de Product Owners, en el ambiente de Scrum. Muchas de las decisiones importantes pasan por él. Por supuesto, no son decisiones en solitario, consulta y recibe asesoramiento de otros interesados. Pero un Product Owner debe ser alguien que realmente se empape del negocio y del producto que queremos lograr. Puede que no sepa todo, pero debe tener el acceso a la información y al conocimiento de otras personas, y tener una mente y actitud de aprendizaje y atención al negocio.

Uno de los anti-patrones de Scrum que mencionaba en el post Anti-Patrones de Sprint era Demasiados cambios en los requerimientos, entre Sprints. Román Mussi comentaba:

Angel, sobre esto:

"Demasiados cambios en los requerimientos, entre Sprints"

Esto no estaría dependiendo del Product Owner? Y en ese caso… como puede intervenir el ScrumMaster para mitigar el problema?

Ciertamente, es un problema que puede nacer de un Product Backlog cambiante. Quisiera aclarar que los cambios pueden ser necesarios: tal vez el negocio de seguros cambión, y la plata ahora está en asegurar camiones: los seguros de vida donde poníamos nuestras fichas fueron afectados por algo, como la llegada de un competidor del extranjero, un cambio en la legislación, o lo que sea. Y esos cambios, el equipo debe enfrentarlos, sin perder impulso, sin sentir el “dolor del cambio”. Scrum, como todo lo ágil, está preparado para fomentar la aceptación del cambio, no de luchar contra él. Pero el anti-patrón aparece si los cambios no son producidos por una nueva evaluación del negocio.

Los cambios así sin sentido de negocio, pueden venir de varias causas. Por ejemplo, un Product Backlog débil inicialmente, que no estaba claro al comienzo, puede ir mejorando al ir entendiéndose mejor el producto a producir, y el negocio en el que está inserto. Igualmente, pediría tratar de evitar esta situación: antes de lanzar el proceso, debería quedar más claro el Product Backlog. No habría que escatimar esfuerzo en tener un buen Product Backlog. Insisto: puede que no sea el final, pero deberíamos haber invertido un tiempo para no desperdiciar tiempo y esfuerzo del equipo. Es claro que no esperamos un “gran diseño inicial”, no es un tema de diseño técnico: es tema de sentido común, sobre lo que queremos obtener.

Pero, por lo menos, si lo anterior tiene olor de anti-patrón inicial, por lo menos el documento evoluciona hacia algo mejor, más firme. Pero otra causa para que aparezca “mal olor” en el Product Backlog (más frecuente de lo esperado, en especial en proyectos largos), es ceder a las presiones externas: de pronto, por atender lo urgente (“tenemos que tener en línea los seguros de autos para la exposición Car2009 que comienza dentro de un mes”), o requerimientos internos de gente con poder en el cliente (“mi división necesita los seguros de camiones para ayer”), el Product Owner cede y cambia el Product Backlog. A ver, pongamos alguna aclaración y contexto: si realmente el futuro de la empresa depende del impacto que tenga en la exposición de autos que viene, entonces es válido el cambio (yo preguntaría entonces: esa exposición estaba planeada desde hace un año, por qué ese cambio de dirección no se previó antes?). Pero si solamente es un cambio promovido por urgencia, y no por importancia, estamos atacando el proceso.

De alguna forma, todo lo ágil, más allá de Scrum, nos trata de proteger del síndrome “lo urgente mata lo importante”. El Product Backlog es el documento primordial, que guía las decisiones del resto del proyecto. El tener un Product Backlog “manteca”, que cambia de forma a cada momento, o según “cómo calienta el sol”, que se modifica incluso en el medio del Sprint (los dioses de Scrum no lo permitan!!), es síntoma de estar reaccionado a lo urgente, en vez de actuando sobre lo importante. El Product Owner, ayudado por el Scrum Master, y el compromiso de la dirección, deberá encarar ese problema.

Espero que haya quedado claro la importancia del rol del Product Owner (en mi postura, el eslabón más débil en Sprint, por ser el que concentra tantas decisiones), y la salud del Product Backlog. Pienso que agregando ejemplos negativos al final, quedó mejor transmitido ese mensaje. He visto proyectos bien llevados, donde todo esto pasa desapercibido, justamente, porque es lo natural. Poner énfasis en los problemas, nos ayuda a entender por qué funciona un proyecto Scrum bien manejado.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

This entry was posted in 10549, 2752. Bookmark the permalink.

3 Responses to Tales from the Scrum: el Product Owner y el Product Backlog

  1. Hola Angel…! Como siempre muy sencilla y didáctica tu explicación. Realmente creo que es positivo para un proyecto que un backlog cambie cuando sea necesario, porque muchas veces esta idea de “biblia de poyecto”, hace que no nos animemos a salirnos del camino. Esto, provoca que el backlog se convierta como en una certificación ISO. Luego, todos creen que variar lo aprobado es perder la certifcación. Y nada está más lejos que eso. Ahora, como vos decís, tiene que haber un criterio y un control, y sobre todo que el desvío pase automáticamente a formar parte del backlog y no que quede como la típica excepción no documentada. Esto agrava la aparición del Antipatrón, y no nos permite aprender de la experiencia. Saludos y gracias como siempre!
    Maxi

  2. Román Mussi says:

    Angel, como siempre muy bueno el artículo. Me permite repensar el rol del Product Owner que es el que más me cuesta visualizar en Scrum. En realidad, comprendo la importancia del rol pero me cuesta ver en la práctica quién lo desempeña.

    En algún sentido tener un buen Product Owner es el sueño de cualquier equipo de desarrollo pero algo que raras veces me ha ocurrido. Por lo general encuentro distintos usuarios interesados en el producto: ejecutivos (gerentes, directores), jefes de área ó coordinadores, usuarios que operan los sistemas, entre otras figuras. Algunas veces con intereses diversos y todos con alguna expectativa respecto del producto a desarrollar. En muchos casos resulta difícil “destilar” un Product Owner de tantos actores en juego. ¿Qué hacer en estos casos?

  3. Claudio Annecchini says:

    Muy claro maestro!!!!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>