¿Backlog o Product Backlog?

Este fin de semana, tuve la oportunidad de participar en un webinar al que fui amablemente invitado por un gran amigo, en donde se hablaba de la importancia del rol del Product Owner y el impacto que este genera, cuando adopta el Mindset ágil, pero además cuando tiene conocimiento y claridad en el uso de técnicas y herramientas de gestión del “Product Backlog”. Por lo que, después de escuchar a los participantes del espacio y recordando un poco lo que me he venido encontrando en los últimos años en los diferentes espacios en los que he participado y en las organizaciones a las que he estado acompañando, nació la idea de escribir este post.

Mi querido amigo lector, haciendo uso de los siguientes principios agiles, quiero exponerte mi conclusión a la pregunta que realizo en el título de este post.

  • Los responsables del negocio y los desarrolladores trabajan juntos.
  • La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
  • La simplicidad es esencial.
  • Los equipos autoorganizados generan mejores arquitecturas, requisitos y diseños.
  • El equipo tiene que reflexionar sobre cómo ser más efectivo para ajustar su comportamiento y su trabajo

Los principios agiles (junto con los valores), representan la base de lo que conocemos como agilidad, por lo que su entendimiento y correcta aplicabilidad, nos permiten habilitar la agilidad a nivel organizacional.

El concepto de “Product Backlog” surgió en la industria del “software”. Ahora, la expresión Product Backlog (si la traducimos literalmente) significa Pila de producto, sin embargo, algunas de las definiciones más usadas son:

  • “Listado ordenado y priorizado de los requisitos necesarios para la implementación de un proyecto”
  • “Es una lista de Historias de Usuario, ordenadas según el valor de negocio que establece el Dueño del Producto, y que trata de cubrir todas las funcionalidades necesarias para desarrollar un producto”
  • “Lista ordenada de todo el trabajo pendiente”
  • “Lista de necesidades que han sido priorizadas, y contiene descripciones breves sobre todo lo que se desea para el producto que se va a desarrollar”

De seguro mi querido amigo lector, has escuchado mas definiciones de las aquí expuestas o quizás tengas tu propia definición. Para lo cual te invito a que analicemos el hecho que con el tiempo el concepto de “Product Backlog”, se ha ido aplicando también al desarrollo de productos y servicios de todo tipo. Lo que nos deja en la paradoja, que ya no estamos hablando solo de producto, y mas si nos vamos a los principios agiles, nos invita a ver que dicho “Product Backlog”, debe contener ítems que sean no solo del producto (Historias de Usuario Funcionales – Aquí se deben incluir incluso las Épicas y Features) sino también de otros factores que son:

  • Habilitadores tanto Técnicos como Exploratorios.
  • Deuda Técnica.
  • Mejoramiento Técnico Continuo.
  • Mejora continua de las cuatro dimensiones: del producto, del proceso, de la forma en que se interactúa (tanto interna como externamente) y de la cultura que se está formando.
  • Bugs identificados a resolver.

Razón por la cual, considero que mas que hablar de “Product Backlog”, deberíamos hablar simplemente de Backlog, dado que este debe contener mas que solo historias de usuario funcionales que hacen referente a un producto, sino que además debe tener como mínimo los ítems anteriormente expuestos.

La gestión por lo tanto del Backlog invita en definitiva también a un equipo mas comprometido, dado que ahora son mas roles/personas que participan (como debe ser) en su creación. Así como también requiere de un Producto Owner mas estratégico, ya que deberá tener clara la visión y la estrategia a seguir, para saber cómo divide la “torta”, según la capacidad del equipo; teniendo en cuenta que se debe por ejemplo pagar la deuda técnica, estar pensando a futuro como mejorar técnicamente la solución e incluso como fomentar la mejora continua de los equipos.

Esto mi querido amigo lector va entre otras cosas, con la propuesta que nos hace Mike Cohn, acerca de tener presente cuatros principios básicos (Acrónimo DEEP) a la hora de construir un Backlog:

  • Detailed appropriately (Detallado apropiadamente)
  • Emergent (Emergente)
  • Estimated (Estimado)
  • Prioritized (Priorizado)

Todos estos ítems del Backlog, por lo tanto, deben ser identificados, gestionados y estimados, llevados a la mesa el día de la planificación y tenerlos presente en el refinamiento. Para así lograr tener una visión compartida del trabajo a realizar.

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.


    
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: