Revisión de Backlog

Un backlog ágil y bien organizado no solo facilita la planificación de lanzamientos e iteraciones, sino que también transmite todo en lo que su equipo tiene la intención de trabajar, incluido el trabajo interno que el cliente nunca notará. Esto ayuda a establecer expectativas con las partes interesadas y otros equipos, especialmente cuando asumen trabajo adicional para usted, y hace que el tiempo del equipo de ingeniería sea fijo.

miniatura de vídeo
¿Qué es una acumulación de productos?
La cartera de productos es una lista de trabajo que el equipo de desarrollo debe realizar, organizada por prioridad. Proviene de la hoja de ruta del producto y sus requisitos. Los elementos más importantes se muestran en la parte superior de la cartera de productos para que el equipo sepa qué hacer primero. El equipo de desarrollo no trabaja en el backlog al ritmo del propietario del producto y el propietario del producto no envía el trabajo al equipo de desarrollo. En su lugar, el equipo de desarrollo extrae trabajo de la cartera de productos según su capacidad, ya sea a un ritmo continuo (Kanban) o por iteración (Scrum).

CONSEJO PROFESIONAL:

Manténgalo todo en un solo rastreador de problemas: no use múltiples sistemas para rastrear errores, requisitos y elementos de trabajo de ingeniería. Si funciona para el equipo de desarrollo, mantén un solo backlog.

Comience con las dos “R”
La hoja de ruta y los requisitos de un equipo proporcionan la base para la acumulación de productos. Las iniciativas de script se dividen en varias épicas, y cada épica tendrá varios requisitos e historias de usuarios. Veamos la hoja de ruta de un producto ficticio llamado Teams in Space.

Hoja de ruta ágil | Entrenador ágil de Atlassian
Dado que el sitio web de Teams in Space es la primera iniciativa en la hoja de ruta, dividiremos esta iniciativa en épicas (que se muestran aquí en verde, azul y verde azulado) e historias de usuarios para cada una de esas épicas.

Iniciativas ágiles y épicas | Entrenador ágil de Atlassian
El propietario del producto organiza las historias de los usuarios en una sola lista para el equipo de desarrollo. El propietario del producto puede decidir ofrecer una epopeya completa primero (izquierda). O puede ser más importante para el programa probar reservar un vuelo con descuento, lo que requiere historias de múltiples epopeyas (derecha). Vea los dos ejemplos a continuación.

Historias ágiles y epopeyas | Entrenador ágil de Atlassian
¿Qué puede influir en la priorización del propietario del producto?

prioridad del cliente
Urgencia para recibir retroalimentación
Dificultad relativa de implementación
Relaciones simbióticas entre elementos de trabajo (por ejemplo, B es más fácil si hacemos A primero)
Si bien el propietario del producto tiene la tarea de priorizar el trabajo pendiente, esas prioridades no surgen de la nada. Los propietarios de productos efectivos buscan comentarios y comentarios de los clientes, diseñadores y el equipo de desarrollo para optimizar la carga de trabajo y la entrega del producto para todos.

Manteniendo el backlog saludable
Una vez que se crea la acumulación de productos, es importante hacer un seguimiento regular del programa. Los propietarios de productos deben revisar el trabajo pendiente antes de cada reunión de planificación de iteraciones para asegurarse de que la priorización sea correcta y que se hayan incorporado los comentarios de la última iteración. La revisión periódica de problemas a menudo se denomina “preparación de problemas” en los círculos ágiles (algunos usan el término refinamiento de problemas).

Cuando crece la acumulación, los propietarios de productos deben agrupar la acumulación en elementos a corto y largo plazo. Los artículos a corto plazo deben realizarse por completo antes de ser etiquetados como tales. Esto significa que se escribieron historias de usuario completas, se organizó la colaboración en el diseño y el desarrollo, y se realizaron estimaciones de desarrollo. Los elementos con plazos más largos pueden permanecer un poco vagos, pero es una buena idea tener una estimación aproximada del equipo de desarrollo para ayudar a priorizarlos. La palabra clave aquí es “aproximado”: las estimaciones cambiarán una vez que el equipo tenga una comprensión completa y comience a trabajar en los elementos a más largo plazo.

El backlog sirve como conexión entre el propietario del producto y el equipo de desarrollo. El propietario del producto es libre de cambiar las prioridades de trabajo en la cartera de pedidos en cualquier momento en función de los comentarios de los clientes, el restablecimiento de las estimaciones y los nuevos requisitos. Sin embargo, una vez que el trabajo está en progreso, realice cambios mínimos, ya que se interponen en el camino del equipo de desarrollo y afectan el enfoque, el flujo y el estado de ánimo.

CONSEJO PROFESIONAL:

Si la acumulación crece más allá de la capacidad a largo plazo del equipo, está bien cerrar elementos que el equipo nunca podrá hacer. Marque estos elementos con una resolución específica como “fuera de alcance” en el rastreador de elementos del equipo para usarlos en futuras búsquedas.

Anti-patrones que deben observarse

El propietario del producto prioriza el trabajo pendiente al principio del proyecto, pero no lo ajusta a medida que pasa la retroalimentación a través de los desarrolladores.

y las partes interesadas.
El equipo limita los elementos pendientes a los que están orientados al cliente.
El trabajo pendiente se mantiene como un documento almacenado localmente y compartido con poca frecuencia, lo que evita que las partes interesadas reciban actualizaciones.
¿Cómo la acumulación de productos mantiene ágil al equipo?
Los propietarios de productos inteligentes organizan rigurosamente la acumulación de productos de sus programas, lo que la convierte en una herramienta destacada confiable y compartible para los elementos de trabajo de un proyecto.

La acumulación permite debates y opciones que mantienen un programa saludable; no todo puede ser una prioridad.

Los partidos desafiarán las prioridades, y eso es algo bueno. Promover la discusión sobre lo que es importante mantiene sincronizadas las prioridades de todos. Estas discusiones fomentan una cultura de priorización de grupos, asegurando que todos tengan la misma opinión sobre el programa.

La acumulación de productos también sirve como base para la planificación de iteraciones. Todos los elementos de trabajo deben incluirse en el backlog: historias de usuarios, errores, cambios de diseño, deuda técnica, solicitudes de clientes, elementos de acción retrospectivos, etc. Esto garantiza que todos los elementos de trabajo se incluyan en la discusión general de cada iteración. Los miembros del equipo pueden comprometerse con el propietario del producto antes de comenzar una iteración con pleno conocimiento de todo lo que se debe hacer.