Backlog del producto: qué es y cómo crearlo

Un backlog de producto saludable se parece mucho a un humano saludable: está bien cuidado, es organizado y pasa tiempo al aire libre.

Dan Radigan De Dan Radigan
Buscar temas

Un backlog ágil bien priorizado no solo simplifica la planificación de iteraciones y publicaciones, sino que también refleja todo a lo que tu equipo dedique tiempo, incluido el trabajo interno que el cliente nunca sabrá. Esto ayuda a establecer las expectativas con las partes interesadas y otros equipos, especialmente cuando te traen trabajo adicional, y consigue que el tiempo de ingeniería sea un activo fijo.

¿Qué es un backlog del producto?

El backlog de un producto es una lista de trabajo ordenado por prioridades para el equipo de desarrollo que se obtiene de la hoja de ruta y sus requisitos. Los elementos más importantes se muestran al principio del backlog del producto para que el equipo sepa qué hay que entregar primero. El equipo de desarrollo no trabaja con el backlog al ritmo que dicta el propietario del producto, y este no presiona al equipo de desarrollo para que saque el trabajo adelante. En su lugar, el equipo de desarrollo saca trabajo del backlog del producto en la medida de sus capacidades, ya sea de forma continua (kanban) o por iteraciones (scrum).

Consejo de experto:

Mantén todo en un gestor de tiques. No uses varios sistemas para realizar el seguimiento de los bugs, requisitos y elementos de trabajo de ingeniería. Si se trata de trabajo para el equipo de desarrollo, mantenlo en un único backlog.

Comienza por las dos erres

La hoja de ruta y requisitos de un equipo son la base para el backlog del producto. Las iniciativas de hoja de ruta se dividen en varios epics, y cada epic tendrá varios requisitos e historias de usuario. Veamos la hoja de ruta de un producto ficticio llamado Equipos en el Espacio.

Ejemplo de backlog ágil | Orientador ágil de Atlassian

Dado que el sitio web de Equipos en el Espacio es la primera iniciativa en la hoja de ruta, dividiremos esa iniciativa en epics (que se muestran aquí en verde, azul y turquesa) y en historias de usuario para cada uno de esos epics.

Iniciativas y epics ágiles | Orientador ágil de Atlassian

A continuación, el propietario del producto organiza las historias de usuario en una única lista para el equipo de desarrollo. El propietario del producto puede optar por entregar primero un epic completo (izquierda), p puede que sea más importante para el programa reservar un vuelo barato que requiera historias de diversos epics (derecha). A continuación, puedes ver ambos ejemplos.

Epics e historias ágiles | Orientador ágil de Atlassian

¿Qué puede influir en la priorización del propietario del producto?

  • Prioridad del cliente
  • Urgencia de tener feedback
  • Dificultad relativa de la implementación
  • Relaciones simbióticas entre elementos de trabajo (por ejemplo, B es más fácil si primero terminamos A)

Si bien el propietario del producto es el encargado de priorizar el backlog, esta tarea no se hace de forma aislada. Los propietarios del producto eficaces buscan los comentarios y las opiniones de los clientes, los diseñadores y el equipo de desarrollo para optimizar la carga de trabajo de todos y la entrega del producto.

Cómo gestionar de forma eficaz el backlog del producto

Una vez creado el backlog del producto, es importante mantenerlo periódicamente para que siga el ritmo del programa. Los propietarios del producto deben revisar el backlog antes de cada reunión para planificar la iteración con el objetivo de asegurar que la priorización es correcta y que se ha incorporado el feedback de la iteración anterior. La revisión periódica del backlog se denomina "limpieza del backlog" en entornos ágiles (hay quien usa también el término "mejora del backlog").

Cuando el backlog aumenta, los propietarios del producto deben agruparlo en elementos a corto y a largo plazo. Los elementos a corto plazo deben estar completamente descritos antes de etiquetarlos como tales. Esto significa que se han diseñado historias de usuario completas, se ha acordado la colaboración con diseño y desarrollo, y el equipo de desarrollo ha realizado estimaciones. Los elementos a largo plazo pueden seguir siendo algo abstractos, aunque es una buena idea tener una estimación aproximada del equipo de desarrollo para ayudar a su priorización. La palabra clave aquí es "aproximada": las estimaciones cambiarán cuando el equipo entienda completamente esos elementos a largo plazo y empiece a trabajar en ellos.

El backlog funciona como conexión entre el propietario del producto y el equipo de desarrollo. El propietario del producto puede cambiar la prioridad del trabajo en el backlog en cualquier momento debido a los comentarios de los clientes, los ajustes de las estimaciones y los nuevos requisitos. No obstante, una vez que el trabajo se está realizando, los cambios deben ser mínimos, ya que interrumpen el trabajo del equipo de desarrollo y afectan a la concentración, el ritmo y el ánimo.

Consejo de experto:

Una vez que el backlog sea mayor que la capacidad a largo plazo del equipo, se pueden cerrar incidencias que el equipo nunca atenderá. Marca esas incidencias con una resolución específica, como "fuera de alcance", en el gestor de incidencias del equipo para usarlo con fines de investigación más adelante.

Antipatrones ante los que estar alerta

  • El propietario del producto prioriza el backlog al inicio del proyecto, pero no lo ajusta a medida que llega el feedback de desarrolladores y partes interesadas.
  • El equipo limita los elementos en el backlog a aquellos orientados a clientes.
  • El backlog se mantiene como un documento almacenado localmente y no es frecuente compartirlo, evitando que las partes interesadas reciban esa información.

Los backlogs del producto ayudan a mantener la metodología ágil de los equipos

Los propietarios del producto con experiencia cuidan rigurosamente el backlog del producto de su programa, convirtiéndolo en un esquema fiable de los elementos de trabajo de un proyecto que se puede compartir.

Las partes interesadas cambiarán las prioridades, y eso está bien. Fomentar las conversaciones sobre qué es importante sincroniza las prioridades de todo el mundo. Estas conversaciones crean una cultura de priorización colectiva que asegura que todos comparten la misma idea del programa.

El backlog del producto también sirve como base para planificar iteraciones. Todos los elementos de trabajo deben incluirse en el backlog: historias de usuario, errores, cambios de diseño, deuda técnica, solicitudes de clientes, elementos de acción de la retrospectiva, etc. Así se garantiza que los elementos de trabajo de todos se incluyan en la conversación general de cada iteración. Los miembros del equipo pueden negociar con el propietario del producto antes de iniciar una iteración con un conocimiento completo de todo lo que debe realizarse.

Consejo de experto:

Los propietarios del producto dictan la prioridad de los elementos de trabajo en el backlog, mientas que el equipo de desarrollo dicta la velocidad a la que se trabaja en el backlog. Esta puede ser una relación poco convincente para los nuevos propietarios del producto que deseen presionar al equipo para que trabaje. Encontrarás más información en nuestro artículo sobre límites y flujo del trabajo en curso.

¿Todo listo para empezar? Aprende a crear tu backlog en Jira Software.

Flecha de metodología ágil

Prioriza lo importante con la plantilla de scrum de Jira

Obtén una visibilidad completa de todo el trabajo que hay que hacer para que puedas centrarte en lo que conseguirá mayor impacto.

A continuación
Revisiones de sprints