14 Cosas que deberías evitar como Product Owner

Ser un buen Product Owner es un tema complejo, dado que unas de sus grandes responsabilidades es organizar y gestionar el Product Backlog con una mirada sistémica que tenga una orientación a resultados tanto para el negocio como para los clientes.

Pero, ¿Por qué es tan importante saber organizar y gestionar el Product Backlog?, mi querido amigo lector, quiero decirte que la importancia radica precisamente en el objetivo principal de éste(el del Product Backlog), el cual podríamos decir que es: “brindarnos esa visión sistémica y transparente del problema a resolver, de la solución que estamos desarrollando y de la mejora continua que debemos aplicar”. Es decir, que el Product Backlog define la dirección por parte del equipo que está desarrollando el producto o la solución. Por lo tanto, hay cosas que como Product Owner deberías evitar hacer, mientras se gestiona este artefacto tan crucial.

Ahora, partamos de la definición oficial del Product Backlog que se encuentra en la guía de Scrum:

«La Lista de Producto (Product Backlog), es una lista ordenada de todo lo que se conoce que es necesario en el producto. Es la única fuente de requisitos para cualquier cambio a realizarse en el producto, el Product Owner es el responsable de la Lista de Producto (Product Backlog), incluido su contenido, disponibilidad y ordenación.”

Sin embargo, aun en la guía de scrum, no solo se queda corta la definición, dada la importancia que este (el Product Backlog) tiene. Sino que además, acota al producto su contenido e incluso limita su gestión al Product Owner, dándole la responsabilidad de su contenido, disponibilidad y ordenación.

Es por eso, que una definición propuesta (la cual expreso en mi libro – Product Backlog, una mirada sistémica) de lo que es un Product Backlog, podría ser:

El Product Backlog, es un artefacto vivo, compuesto por una serie de ítems que representan una visión sistémica, de lo que ha de ser una solución y de lo que las personas involucradas en el desarrollo de dicha solución deben hacer, para garantizar su crecimiento como equipo y la entrega temprana, constante y continua de valor.”

Ahora, adicionalmente a la definición, la guía plantea:

«Una Lista de Producto (Product Backlog) nunca está completa. El desarrollo más temprano de la misma solo refleja los requisitos conocidos y mejor entendidos al principio. La Lista de Producto (Product Backlog) evoluciona a medida que el producto y el entorno en el que se usará también lo hacen. La Lista de Producto (Product Backlog) es dinámica; cambia constantemente para identificar lo que el producto necesita para ser adecuado, competitivo y útil. Mientras el producto exista, su Lista de Producto (Product Backlog) también existe.”

«La Lista de Producto (Product Backlog) enumera todas las características, funcionalidades, requisitos, mejoras y correcciones que constituyen cambios a ser hechos sobre el producto para entregas futuras. Los elementos de la Lista de Producto (Product Backlog) tienen como atributos la descripción, la ordenación, la estimación y el valor.”

«A medida que un producto es utilizado y se incrementa su valor, y el mercado proporciona retroalimentación, la Lista de Producto (Product Backlog) se convierte en una lista más larga y exhaustiva. Los requisitos nunca dejan de cambiar, así que la Lista de Producto (Product Backlog) es un artefacto vivo. Los cambios en los requisitos de negocio, las condiciones del mercado o la tecnología podrían causar cambios en la Lista de Producto.”

Mi querido amigo lector, quiero decirte que en muchos casos, la mala interpretación de los párrafos expuestos, hace que se presenten las cosas que te invito a evitar como Product Owner:

Creer que el Product Backlog está compuesto solo de Historias de Usuario, o en su defecto solo de ítems funcionales

Este es uno de los grandes errores que se presentan en muchos equipos, como ya pudimos ver en un post anterior (el cual puedes leer aquí). El Product Backlog esta compuesto por una serie de ítems que permiten que se logre esa mirada sistémica que se espera de este importante artefacto de cara al cumplimiento de su objetivo.

Creer que el Product Owner, es el único que puede crear los ítems del Product Backlog

Si miramos los tipos de ítems que contiene un Product Backlog, vemos que al no tener tiene solo ítems funcionales, roles como el del Arquitecto de la solución, los lideres Técnicos, los UX, desarrolladores e incluso los Scrum Master, tienen la responsabilidad de contribuir en la creación de los ítems del Product Backlog cada uno desde su área de acción. Con el fin de contribuir el lograr esa mirada sistémica que se espera tenga el Product Backlog.

Creer que el Product Owner es el único responsable de gestionar los ítems del Product Backlog

El paradigma con el que normalmente venía trabajando el Product Owner, puede ser la razón de este malentendido. Dado que, en las metodologías tradicionales, los requisitos no se gestionan en colaboración, por lo general era una única persona la encargada de la gestión de requerimientos, sin embargo en un entorno ágil, teniendo presente los distintos tipos de ítems que contiene el Product Backlog, no tiene sentido continuar con este tipo de paradigma. Ya que una gestión permite establecer una mejor estrategia de cara a la consecución de los objetivos trazados.

Pretender crear todo el Product Backlog al inicio del proyecto

En este sentido hay que recordar siempre se un proyecto o el desarrollo de un producto o solución bajo un enfoque ágil, parte de la premisa que se desarrolla en un entorno empírico y que mediante la continua inspección y adaptación se va ajustando el camino a seguir. por lo que pretender crear todo el Product Backlog al inicio, es comenzar con un enfoque de agilidad cosmética.

No tener el Product Backlog Organizado

Este es otro de los grandes errores que comenten muchos equipos, ya que al no tener el Product Backlog organizado, se mantiene un enfoque a entregables (outputs) mas no a resultados (Outcomes), motivo por el cual, toma relevancia organizar el Product Backlog, teniendo una estrategia de liberación y un plan de liberación claros y que se puedan ir ajustando con el paso del tiempo según los resultados obtenidos.

No tener claro el tipo y el valor que se espera generar

Si no tener el Product Backlog organizado, es no tener un enfoque a resultados, no tener claro el tipo y el valor que se va a generar, podría considerarse una irresponsabilidad con la organización. Dado que, al no tener esto claro, la organización no solo no tendría información del beneficio real entregado a los clientes sino que además tampoco podrá determinar temas como el retorno de la inversión (ROI), el Retorno de eficiencia (ROE) entre otros. Es decir seria como estar invirtiendo en una solución, que no se sabe si es o no rentable.

Desarrollar un Plan de liberación con estimaciones de alto nivel

¿Te imaginas comprarle un par de zapatos a tu esposa, sin llevarla a ella a que los escoja y se los mida?, del mismo modo imagínate pretender entregar algo sin contar la estimación de tiempo de quien realmente va ha realizar la labor esperada. Este es un problema que se presenta en muchas organizaciones por su afán de iniciar proyectos y de tener esa sensación de falsa seguridad y control que te brinda una fecha dada por lo general por un jefe o un gerente de proyectos. Un buen Product Owner, sabe que las estimaciones de alto nivel brindan esa falsa sensación de seguridad y control, que al pasar el tiempo terminan siendo efímeras, por lo que para la construcción de su plan de liberación este tiene en cuenta el refinamiento y la estimación realizada por el equipo de desarrollo, quienes son los que realmente van a desarrollar el producto o la solución, de tal forma que entendiendo que la estimación es un tema relativo, construye un plan de liberación acorde a la realidad del contexto.

Contar con múltiples Product Backlog, por ejemplo, uno funcional, uno técnico, uno de mejora continua, etc.

En un enfoque ágil, el trabajo colaborativo es un punto muy importante, por lo que, a pesar de que un Product Backlog contiene distintos tipos de Ítem, este es al final un único artefacto valido que contiene el amalgama de todos estos, de tal modo que logre darnos esa visión sistémica, de lo que ha de ser una solución y de lo que las personas involucradas en el desarrollo de dicha solución deben hacer, para garantizar su crecimiento como equipo y la entrega temprana, constante y continua de valor. Y no fomentar así, los ahora tan presentes silos agiles.

No realizar revisión y refinamiento frecuente de los ítems del Product Backlog

La misma guía de Scrum nos lo indica, el refinamiento del Product Backlog es un proceso continuo. Por lo tanto, este no debe considerarse una ceremonia o evento, de tal modo que se incurra con esto en el error de realizar la revisión y el refinamiento solo un par de días establecidos en la semana, recordemos que la realización constante de la inspección, nos brindará las herramientas necesarias para la adaptación y por otro lado, el refinamiento continuo permitirá un mayor conocimiento, entendimiento y comprensión de las necesidad a resolver, así como también del trabajo necesario a realizar.

Tener los ítems del Product Backlog sobre refinados, lo que crea un Product Backlog tamaño XXL

Si bien el refinamiento en un proceso continuo y que debe realizarse a todos los ítems del Product Backlog, hay que tener cuidado en plasmar en este hasta el más mínimo detalle de cada una de las tareas que se deben realizar, las cuales si bien son importantes de identificar, el poblar el Product Backlog con estas, podrá acarrear problemas en la gestión de este, así como también confundir el mensaje que este debería trasmitir a quien intente leerlo.

Pretender ser el único que debe de participar en la creación de la Historias Funcionales

Hay que tener presente que “Una Historia de usuario es una corta declaración de intención que describe algo que el sistema necesita hacer para el usuario. Y se describe desde el punto de vista de quien usará la funcionalidad”. Pero sobre todo que esta, es el resultado de una conversación en la que se busca el conocimiento, entendimiento y comprensión de la necesidad a resolver. Por lo que lo importante no es quien la escriba, sino que se logre precisamente entender esa necesidad a solucionar. Ahora, los distintos roles del equipo pueden realizar aportes importantes, como por ejemplo los analistas de QA de cara a una mejor definición de los criterios de aceptación, incluso si tomamos en cuenta un enfoque TDD, esto permite aun mejor resultado. Por lo que como Product Owner enfócate en que existan las Historias de Usuario necesarias para solucionar el problema, y que en su construcción participen todos aquellos que aportan valor a lograr dicha comprensión del problema.

Presentarse solo el día del Planning y posteriormente el día de la Review

En este sentido hay que tener presente que como Product Owner, haces parte del equipo, por lo que es de suma importancia que recuerdes el principio ágil que dice: “Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.” Si, así como lo lees, juntos, de forma cotidiana, a lo largo de todo el proyecto, NO solo en unos eventos específicos. Con el fin de lograr estar sintonizados, empoderados y alineados en todo lo referente. Recuerda que entre otras cosas no se esta construyendo o desarrollando un producto o una solución, también se esta buscando construir un equipo de alto desempeño que logre grandes resultados.

No participar de la Daily del Equipo

Una vez más, debes tener presente que tú haces parte del equipo, por lo que es importante que participes en la sincronización diaria (entendiendo que NO es un espacio de seguimiento, sino de sincronización y definición de los objetivos del día). Y que por sobre todo, lo que te permitirá tener información, para si saber los riesgos presentados, o los posibles ajustes que se deban hacer a la estrategia, o información relevante que deba ser elevada a los Stakeholders, entre muchos otros.

No participar de la retrospectiva del equipo

Por ultimo y una vez más, aunque suene cansón, tú haces parte del equipo y debes participar en el proceso de mejora continua, sería muy egocéntrico pensar que no tienes nada que mejorar… Como haces parte del equipo tu contribuyes a su mejora en todas sus dimensiones, por lo que tu participación aquí debe ser precisamente eso participativa, propositiva, mas no impositiva ni observativa.

Por último, mi querido amigo lector, quiero dejar un par de frases para tu reflexión:

“El empirismo afirma que el conocimiento proviene de la experiencia y toma decisiones basadas en lo que se conoce.” – La guía Scrum

“Individuos e interacciones sobre procesos y herramientas.” – Manifiesto ágil

Por lo tanto involúcrate y compenétrate con el equipo, ya tu haces parte de él. Recuerda, que la gestión del Product Backlog en un proceso continuo y colaborativo. Y que un Product Backlog orientado a resultados, genera mayor valor a los clientes y a la organización, lo cual refleja la existencia de un buen Product Owner. De tal modo, que ten cuidado, y no vivas en una agilidad cosmética.

Si quieres aprender mas, te invito a que le des un lectura a mi libro: Product Backlog, una mirada sistemica (Aqui). En donde te ofrezco una visión completa de lo que es el Product Backlog y su importancia en el desarrollo de productos y soluciones que generen valor al cliente. Ademas de mostrarte como crear, organizar y gestionar product backlog orientado a outcome (resultados) por encima de output (entregables).

Pd:Te invito a dar un vistazo a mi libro recomendado del mes (Clic Aquí)

Gracias por tu tiempo.

Saludos,


También te puede interesar Leer



SUSCRÍBETE A MI BLOG

Y cada vez que realice una nueva publicación, recíbela al instante.


Una respuesta a «14 Cosas que deberías evitar como Product Owner»

    
Suscríbete al Blog
Y entérate cada vez que realice una nueva publicación.
Suscribirse
Te puedes dar de baja cuando lo desees!
close-link
A %d blogueros les gusta esto: