Una de las bases importantes en Scrum es el “Product Backlog”, pero…

¿Qué ese el Product Backlog?

Aquí vamos:

En la definición más simple, el Product Backlog es simplemente una lista de todas las cosas que deben hacerse dentro de un proyecto. Reemplaza los artefactos de especificación de requerimientos tradicionales. Estos elementos deben de estar centrados hacia el valor del cliente, por ejemplo, en forma de historias de usuario ordenadas según el valor de negocio que establece el Product Owner, y que trata de cubrir todas las funcionalidades necesarias.

¿Para qué sirve?

¿Cómo se hace?

Solo entradas que agregan valor.

Cada entrada en el Product Backlog debe tener algún tipo de valor para el cliente. Las entradas sin ningún valor para el cliente son un desperdicio puro y no deberían estar presentes de todos modos. Puede incluir entradas para la exploración de las necesidades del cliente o varias opciones técnicas, una descripción de los requisitos funcionales y no funcionales, el trabajo necesario para lanzar el producto y otros elementos, como la configuración del entorno o la remediación de defectos. Algunas tareas pueden no agregar valor directo a la funcionalidad. Sin embargo, podrían agregar valor al aumentar la calidad o reducir los incidentes a largo plazo.

Documento viviente

El Product Backlog se modifica a lo largo de todo el proyecto. Si es necesario, se agregan nuevos requerimientos y los requerimientos existentes pueden modificarse, definirse con más detalle o incluso eliminarse. Los requerimientos ya no están congelados desde el principio. En su lugar, el conjunto final de requerimientos dentro del Product Backlog también se desarrolla de manera iterativa. Esto es diferente a la ingeniería de requerimientos tradicionales, pero permite maximizar el valor del cliente y minimiza el esfuerzo de desarrollo.

Diferente nivel de detalles

Los requerimientos del Product Backlog tienen una granularidad diferente. Solo aquellos requerimientos que se implementarán durante las próximas semanas se definen con mayor detalle y todo lo demás es más general. La razón simple de esto es que no tiene sentido invertir tiempo y esfuerzo en la especificación de estos requerimientos, ya que la mayoría de estos requerimientos habrán cambiado de todos modos hasta que comience la implementación.

No hay tareas de bajo nivel

El Product Backlog no contendrá la información detallada de requerimientos. Idealmente, los requerimientos finales se definen junto con el cliente durante una junta. El desglose y la distribución de estos requerimientos es responsabilidad del Equipo de trabajo.

Product Backlog es ordenado

Todas las entradas se priorizan y se ordena en el Product Backlog. El Cliente con la ayuda del Equipo hace la priorización. El valor agregado, los costos y los riesgos son los factores más comunes para la priorización.

Todas las entradas son estimadas

Todas las entradas dentro del Product Backlog deben estimarse de acuerdo con la definición acordada (por ejemplo, puntos de historia). Esta estimación se puede utilizar para priorizar las entradas en el Product Backlog y para planear lanzamientos.

Trabajando con el Backlog

El Product Backlog necesita atención y cuidados regulares, y debe gestionarse con cuidado. Al comienzo del proyecto, el Equipo y el Cliente comienzan escribiendo todo lo que pueden pensar fácilmente. Esto es casi siempre más que suficiente para una primer junta.
Después de esta configuración inicial, el Product Backlog debe mantenerse en un proceso continuo que comprende los siguientes pasos:

El Cliente es responsable de asegurarse de que el Product Backlog esté en buena forma, este es un proceso de colaboración. Al usar el Marco Scrum, aproximadamente el 10% del tiempo total de los equipos debe reservarse para mantenerlo (discusión, estimación, etc.).

El mantenimiento colaborativo del Product Backlog ayuda a aclarar los requisitos y crea una aceptación del Equipo

Historias de usuario

Las entradas en el Product Backlog son a menudo escritas en forma de Historias de usuarios. Una historia de usuario habla sobre alguien que usa el producto, ya sea el usuario, área de negocio o cliente.

Esto contiene un nombre, una breve narración, criterios de aceptación y condiciones para que la historia este completa. La ventaja es que se centran en exactamente lo que el usuario necesita o quiere sin adentrarse en los detalles sobre cómo lograrlo.

Usando la fórmula siguiente podrás sustituirla con tus historias de usuario:

Yo como un [Rol], necesito [Descripción de la funcionalidad], con la finalidad de [Descripción de la consecuencia] y podrás guiarte con los siguientes ejemplos

Esta épica se puede subdividir en:

Otros ejemplos:

No importa a que área pertenezcas, a todas se puede aplicar y se puede hacer referencia al usuario, área de negocio o el cliente. ¡Ahora a practicar!
Errores frecuentes:

Trabajar con un Product Backlog no significa que el equipo de trabajo no tenga permitido crear y usar otros artefactos. Los ejemplos de artefactos adicionales podrían ser un resumen de los distintos roles de usuario, descripciones de flujo de trabajo, pautas de interfaz de usuario, guiones gráficos o prototipos de interfaz de usuario. Sin embargo, estos artefactos no reemplazan el Product Backlog, sino que complementan y detallan su contenido.

Autor: Karina Martínez

¡Y esto solo es una pequeña parte de Scrum! Estaremos generando más contenido, así que no te lo pierdas! y comenta que tema te gustaría profundizar.

*Checa nuestros planes de carrera para saber que certificación es la más adecuada para ti y  consulta nuestros próximos cursos