El Product Backlog – La intención del equipo

Cuando empezamos con un equipo que hace “algo de Agile”, encontramos muchos puntos de mejora para empezar a trabajar con ellos. Trabajar como consultores nos da la oportunidad de poner en práctica todos los conceptos y valores que llevamos años enseñando. 

De todos estos hilos que surgen, hay algunos que se repiten con más asiduidad. Entre ellos están:

Relacionado
Motivación y Compromiso en la empresa con M3.0

Como puedes ver, existen muchas vías de mejora. Siempre se puede mejorar, pero la base está en ser conscientes de que necesitamos mejorar. Puede que este sea el mayor de todos los retos: Abrir los ojos y las mentes de los que viven la transformación.

Empecemos por el principio: El Producto

¿Qué hacemos cuando llegamos a un equipo que ni siquiera sabe para qué existe su producto? Claramente necesitamos entender esta situación. 

Supongamos que estamos “trabajando con Scrum”. Falta de transparencia, de comunicación, de equipo… Puede que el Product Owner no esté ejerciendo su labor  respecto al equipo, puede que ni siquiera esté presente en el día a día o que directamente haga las labores de un Stakeholder. 

¿Y el Scrum Master? ¿Es una persona dedicada a asegurar que Scrum se ejecuta correctamente o tiene más de un sombrero que no debería? Es posible que, si hay mucho desconocimiento y falta de implicación por lo mismo, Scrum o cualquier otro marco de trabajo se convierta en un circo con payasos.

“Para que un equipo pueda implicarse, necesita entender para qué hace lo que hace.” 

planificar por capas en entornos Agile

Planificar por capas en entornos Agile

Una vez que el equipo entiende la misión de su trabajo y la visión de negocio podemos empezar a trabajar en otros aspectos más mundanos y no por ello menos importantes.

El Product Backlog

Tener claros todos los conceptos nos ayudará a utilizarlos mejor y entender el para qué de las cosas. En Scrum el Product Backlog es una lista ordenada de elementos necesarios para construir el producto. Todo tipo de trabajo ejecutable tiene cabida aquí siempre y cuando ayude a la construcción y evolución del producto.

Elementos que pueden encontrarse en un Product Backlog:

  • Tareas. Entendiéndolo como tarea y no subtareas de otro tipo de elemento.
  • Funcionalidades.
  • Requisitos técnicos y funcionales.
  • Casos de uso.
  • Mejoras.

Ninguno de los elementos listados arriba es obligatorio, al igual que ninguno es imprescindible. He podido ver Product Backlogs en los que la mayoría de elementos eran mejoras porque el producto ya estaba operativo desde hacía tiempo y no había novedades a corto plazo.

Dentro del Product Backlog siempre podemos utilizar prácticas recomendadas como las Historias de Usuario y las Épicas para organizar los elementos. Otra función importante que cubrimos con esta técnica es la de dar más transparencia de cara a personas ajenas al desarrollo como pueden ser los propios usuarios. 

Elementos que no forman parte del Product Backlog:

  • Eventos.
  • Reuniones.
  • Actividad de refinamiento.
  • Actividades de Teambuilding.
  • Reportes.

Estos elementos listados arriba no pueden formar parte del Product Backlog como elemento ejecutable, ya que por ellos mismos no aportan valor al incremento. Pueden ser necesarios para llevar a cabo otros elementos, pueden ser consecuencia de otros elementos o como en muchos casos he llegado a ver, gestión de las personas del equipo y el tiempo que dedican a los elementos.

Excepción

Como puedes ver en el listado inferior, el Product Backlog no contiene todo lo que hacemos ni pretende justificar por qué se nos paga por las horas que estamos trabajando. En resumen: si es un elemento necesario para el producto que aporta valor el usuario, aparece. Si no es así, no debe aparecer.

Cuando no hay producto

Hay muchas otras formas de trabajar en las que primero se necesita tener una lista de elementos para ir cogiendo y ejecutando. Pero si al final del proceso no entregamos un incremento en un producto, como puede ser software, documentación o incluso experiencias turísticas (por ejemplo), no tienes un producto y por tanto no tienes un Product Backlog. Tendrás una lista de elementos para hacer. Trabajar por proyectos no incapacita el uso de Scrum. En Scrum un Sprint puede considerarse un proyecto como en el caso de las releases.

En el método Kanban puedes tener un Backlog de elementos diferentes con distintos fines, por eso se utilizan los Work Item Types y las Clases de Servicio, para tener claras las prioridades de cada tipo de trabajo. Aunque esto te pueda permitir un abanico más grande en cuanto a tipos de elementos siguen existiendo (como en el caso de Scrum) elementos que no tiene sentido que se encuentren en el Backlog. En cualquier caso, ni Scrum, ni Kanban, sirven para justificar nuestro trabajo sino para gestionar sistémicamente trabajo y que las personas se auto-organicen alrededor de dicho sistema.

Y tú, lector ¿tienes claro si hay producto o es un servicio?

Avatar for Laura Jiménez

Posted by Laura Jiménez

Desde que conocí el mundo Agile el mio ha cambiado para mejor y quiero ayudar a otras personas a conseguir lo mismo. Soy Scrum Master con base de Diseño Gráfico y Maquetación Web. Siempre se puede mejorar y me encanta explorar las alternativas con las personas con quien trabajo.

Deja un comentario

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

Para comentar debes aceptar nuestra política de privacidad

Suscribete a nuestra lista de correo

Suscribete a nuestra lista de correo

Recibe actualizaciones en la comodidad de tu bandeja de entrada. Un email a la semana. Sin Spam. Sin Trucos.

Suscripción con éxito

Shares
Share This