fbpx

Go-Productivity

SCRUM: ¿Qué ese el Product Backlog y para qué sirve?

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?

  • Cada Product Backlog tiene ciertas propiedades que lo diferencian de una simple lista de requerimientos pendientes:
  • Una entrada en el Product Backlog siempre agrega valor para el cliente.
  • También permite que el cliente pueda introducir cambios durante la vida del proyecto.
  • Las entradas en el Product Backlog se priorizan y ordenan en consecuencia.
  • Maneja la incertidumbre durante el proyecto porque ayuda a describir con más detalle las tareas más importantes.
  • Todas las tareas son estimadas.
  • Es más ligero que un documento de requerimientos exhaustivo.
  • No hay elementos de acción ni tareas de bajo nivel.

¿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:

  •  A medida que se descubren nuevos elementos, se describen y agregan a la lista. Los existentes se cambian o eliminan según corresponda.
  • Ordenar el Product Backlog. Los elementos más importantes se mueven a la parte superior.
  • Preparar las entradas de alta prioridad para la próxima junta
  • Reestimación de las entradas en el Product Backlog

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

  • Como Vicepresidente de mercadeo y ventas, quiero /necesito revisar el desempeño histórico de las ventas, para poder identificar las regiones geográficas y productos de mejor desempeño

Esta épica se puede subdividir en:

  • Como VP de Mercadeo, quiero seleccionar el período de tiempo en el cual realizaré la revisión de las ventas.
  • Como VP de Mercadeo, necesito clasificar la información de ventas por región geográfica y productos.

Otros ejemplos:

  • Como Ejecutivo de cuenta, quiero /necesito que el sistema me indique cuales son los documentos que debo solicitar al cliente para procesar su solicitud de crédito hipotecario.

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:

  • Cambiar prioridades sin el consentimiento del Product Owner.
  • Introducir en el Product Backlog historias de deuda técnica. Los defectos del equipo no los paga el cliente, sino que reducen la velocidad.
  • Preocuparse por describir con mucho detalle historias que están muy abajo en el Product Backlog.
  • No actualizar el plan (¿qué pretendemos entregar en cada nueva versión?) cuando introducimos nuevas historias o reestimamos las existentes.

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 

One comment

Deja un comentario

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