Go to Scrumio.com

El Product Owner y sus interacciones con el Equipo de Desarrollo

Como comentábamos al hablar sobre el buen Product Owner, la colaboración continua entre este y el Equipo de Desarrollo durante el Sprint es fundamental. En particular, tal colaboración se proyecta en al menos cinco ámbitos:

1/ Dudas. Es normal que a los miembros del Equipo de Desarrollo les surjan preguntas relacionadas con la funcionalidad en la que están trabajando, a medida que avanzan, y que necesiten consultar con el Product Owner. Cada día, de forma explícita o implícita, tomamos multitud de decisiones de producto al resolver tales cuestiones. La falta de disponibilidad del Product Owner para asistir al Equipo con estas dudas podría, incluso, enlentecer o bloquear el trabajo en curso durante el Sprint.

2/ Feedback. Si es en la Sprint Review cuando el Product Owner ve el Incremento de Producto por primera vez, algo falla. El Product Owner debe poder “trastear” las funcionalidades que forman parte del Sprint a lo largo de este, y así dar feedback útil al Equipo, que ayude a completarlas. Insisto, la Sprint Review no debe ser utilizada por el Product Owner para aceptar o rechazar el Incremento -esta es una de las disfuncionalidades típicas de la Sprint Review-.

3/ Negociaciones sobre el alcance del Sprint. Esta negociación empieza desde la Sprint Planning -o, incluso, desde el refinamiento previo-, cuando el Product Owner propone qué elementos del Product Backlog incluir en el Sprint y el Objetivo del Sprint -Objetivo que ha de enlazar con la visión de producto-.

Durante el Sprint, puede que el Equipo de Desarrollo se de cuenta de que ha seleccionado demasiado o no suficiente trabajo, y que sea necesario quitar o añadir otros elementos del Product Backlog, ajustando el alcance del Sprint de manera que su Objetivo aún pueda alcanzarse.

Asimismo, esta adaptación del alcance del Sprint puede producirse a iniciativa del Product Owner, en caso de que, por ejemplo, el valor de alguno de los elementos del Sprint decayera y deba ser sustituido o no por otro. Aquí el Product Owner debe ser prudente y tener en cuenta que cambios arbitrarios pueden afectar a la moral y productividad del Equipo de Desarrollo. Con frecuencia, mi recomendación es esperar al siguiente Sprint y no “liar” al Equipo de Desarrollo, a menos de que se trate de aspectos absolutamente críticos, que rara vez lo son.

4/ Refinamiento. El refinamiento no es una reunión obligatoria en Scrum, aunque es tan aconsejable que quizás debería serlo. Refinar el Product Backlog consiste en añadir detalle y estimaciones a sus elementos, a fin de prepararlos para ser abordados en próximos Sprints. Este ejercicio de refinamiento debe ser realizado de manera colaborativa entre el Product Owner y el Equipo de Desarrollo, sin superar el 10% de la capacidad de este para el Sprint. No hacer refinamiento es arriesgarse a que la Sprint Planning sea poco eficiente y a que empecemos el Sprint con el pie cambiado. “Get to ready to get to done”, como dicen los anglosajones.

5/ Discovery. El discovery de producto alude a todas aquellas actividades encaminadas a determinar qué funcionalidades o productos merecen ser creadas, por tener el suficiente valor potencial. Me refiero a análisis de datos, entrevistas con clientes, creación de experimentos, etcétera. El Product Owner lleva a cabo estas actividades implicando a los miembros del Equipo de Desarrollo todo lo posible, incluyendo no solo a diseñadores de UX / UI, sino también a los ingenieros de software.

La motivación del Equipo de Desarrollo depende directamente de la capacidad que tenga el Product Owner para hacer a sus miembros partícipes del problema o necesidad que estamos intentando satisfacer. Queremos a un Equipo de Desarrollo de misionarios, no de mercenarios.


El Scrum Master, por su parte, debe velar porque estas interacciones tengan lugar y se produzcan de la forma más fluida posible. La Sprint Retrospective, en la que el Product Owner también ha de estar presente, como parte del Equipo Scrum, nos brinda la oportunidad para inspeccionar las relaciones entre Product Owner y Equipo Desarrollo, e identificar apartados de mejora.

Comparte este post

Publicado por Sergio Rodríguez

Chief Product Officer and Product Consultant for several international startups throughout his career, such as Liftshare.com, Hiyacar and Cardmarket. Agile practitioner for over 10 years and PSPO III certified. Obsessed with creating products that people love.

Posts relacionados

Comentarios

Deja tu comentario

Tu dirección de correo no será publicada. Lo campos requeridos están marcados con *

Recibe artículos sobre ágil y promociones en tu email.