Siempre tuve la impresión de que Sprint Backlog es parte de Product Backlog -> es imposible agregar algo a Sprint Backlog sin afectar Product Backlog
Sin embargo, según uno de los comentarios de esta publicación , estos retrasos "son artefactos completamente diferentes"
Estamos utilizando un tablero Scrum electrónico; ¿Sería posible agregar cosas como elementos de nuestra retrospectiva a la cartera de pedidos de Sprint y evitar estropear la cartera de productos?
El Dueño del Producto es dueño del Product Backlog y lo prioriza en nombre de las partes interesadas. El Sprint Backlog es propiedad del Equipo, y ellos son los únicos árbitros de su contenido.
El Sprint Backlog contiene historias de usuarios que aparecieron en la parte superior del Product Backlog durante la Planificación del Sprint. Sin embargo, el Sprint Backlog generalmente contiene muchas cosas que no están en el Product Backlog, como:
El objetivo del Sprint y las historias aceptadas para el Sprint actual se establecen durante la planificación de primavera, pero el equipo actualiza y modifica las tareas (y, ocasionalmente, las historias) en el Sprint Backlog de la manera que considere adecuada: es el artefacto del equipo y suyo. gestionar en apoyo del Sprint Goal.
Si bien las historias aceptadas en el Sprint Backlog durante la Planificación del Sprint generalmente son fijas, si el equipo termina antes de tiempo, se les anima a sacar trabajo adicional del Product Backlog si creen que puede encajar en el Sprint actual sin comprometer el Sprint Goal. Además, a veces sale a la luz información o conocimientos adicionales durante el Sprint, y el equipo y el propietario del producto pueden eliminar historias del Sprint de manera cooperativa si hacerlo ayuda al equipo a alcanzar el objetivo del Sprint actual.
Además, las historias de usuario son puntos de partida para las conversaciones con las partes interesadas (o el Dueño del producto si se hace por medio de un proxy), por lo que es bastante común agregar y eliminar tareas del Sprint Backlog a medida que se trabajan las historias. Parte del arte de Scrum está en diferenciar entre los refinamientos que provienen de reducir el cono de incertidumbre durante un Sprint de los cambios a las historias que ponen en peligro el Sprint Goal.
En general, los elementos del Backlog del Sprint deben ser desgloses de los elementos del Backlog del Producto o tareas de apoyo que unen las historias en el Sprint actual. Una vez más, el arte está en diferenciar entre las tareas que el equipo debe crear en el Sprint Backlog para respaldar el Sprint Goal y las historias que deben colocarse en el Product Backlog.
Como ejemplo, si tiene una historia que requiere que cree una base de datos, es posible que deba agregar una tarea a su Sprint Backlog para instalar un nuevo servidor de base de datos. Por lo general, esta tarea se agregaría durante la Planificación del Sprint, pero es posible que la tarea no se vuelva obvia hasta más adelante en el Sprint. En tales casos, es perfectamente aceptable agregar las tareas recién descubiertas al Sprint Backlog siempre que no comprometan el Sprint Goal o invaliden las historias aceptadas en el Sprint.
Las historias de equipo más allá de eso pertenecen propiamente al Product Backlog. Por ejemplo, configurar una arquitectura de base de datos completa es una historia que el propietario del producto debe priorizar como requisito previo para otras historias en la cartera de productos. Estos tipos de historias generalmente se agregan durante la preparación del trabajo pendiente y, ocasionalmente, durante la planificación del Sprint; después de eso, se tratan como cualquier otra historia en el Product Backlog.
[S]ería posible agregar cosas como elementos de nuestra retrospectiva en la cartera de pedidos de Sprint y evitar estropear la cartera de productos?
Eso depende. Si su Sprint Retrospective conduce a cambios en el proceso o tareas dentro del sprint para el equipo, entonces, por supuesto, esas cosas deben agregarse a uno de los trabajos pendientes. Las tareas y los procesos internos pertenecen al Sprint Backlog; los subproyectos que consumen tiempo o recursos fuera de las estimaciones de historias individuales pertenecen al Product Backlog.
No tenga miedo de "estropear el Product Backlog". El Product Backlog no es un documento inviolable e inmutable. Un proceso de Scrum saludable debe alentar las conversaciones continuas entre el propietario del producto y el equipo, y alentar la adición de historias de infraestructura y cadena de herramientas a la cartera de productos para que sus costos y beneficios sean visibles para el proyecto y la organización.
No estás completamente equivocado en tu impresión del Sprint Backlog. El Product Backlog es la herramienta utilizada por el propietario del producto para realizar un seguimiento de todas las características que a las partes interesadas les gustaría ver implementadas en el producto, mientras que el Sprint Backlog es un subconjunto del Product Backlog que representa la iteración activa actual del Sprint.
De The IT BA - Product Backlog vs Spring Backlog :
Una cartera de productos es una lista de todas las características deseadas del producto (ya sea que planee implementarlas o no).
Cualquiera puede agregar cualquier cosa al Product Backlog en cualquier momento. Sin embargo, el propietario del producto lo prioriza. Entonces, si usted y yo agregamos una solicitud de función para agregar una función de cotización del día a un producto, el propietario del producto podría muy bien poner esto en la parte inferior de la pila, lo que significa que realmente no tiene la intención de agregar esa función.
El trabajo pendiente de Sprint es una lista de tareas pendientes de los elementos del trabajo pendiente que se completarán en la iteración actual.
El Sprint Backlog, por otro lado, representa la iteración actual del Sprint, y una vez que comienza un Sprint, nadie debe agregar o eliminar nada del Sprint Backlog. El Sprint Backlog es elaborado por el equipo, y en caso de que esto no esté claro, solo por el equipo, seleccionando elementos de la parte superior del Product Backlog. Si algo no está en el Product Backlog, entonces no debería estar en el Sprint Backlog.
Si más tarde alguien quiere agregar la función Y a la lista, y es un elemento de alta prioridad, todavía va a la lista de pedidos del producto, y si es una función lo suficientemente importante, el propietario del producto puede moverla a la parte superior de la lista de pedidos del producto para que que es probable que se seleccione en la próxima iteración de Sprint.
La relación jerárquica entre una acumulación de producto y una acumulación de sprint es causada por la configuración de la iteración en su línea de tiempo (al hacer que las iteraciones de sprint sean secundarias de la iteración de lanzamiento). Cada línea de tiempo puede tener una iteración de Backlog (que normalmente estaría asociada con Product Backlog).
No puedo pensar en ninguna ventaja de hacer de Scrum Backlog Tool una iteración principal. Al asociarlo con la línea de tiempo como la iteración de Backlog definida, obtiene un estado especial. Agregarlo a la jerarquía de iteraciones probablemente solo desmenuce las cosas (tendrá más capas para navegar al elegir una iteración, por ejemplo). También puede causar problemas con las visualizaciones acumuladas en los planes: ahora puede ver acumulaciones en la Lista de productos pendientes, que no es su propósito y puede dificultar el trabajo con ellas.
Todd A. Jacobs
jmort253