Esa evolución se da a través de los Sprints, a medida que:
- Se pasan ítems al Sprint Backlog, durante la Planning.
- Se agregan nuevos ítems que sean valiosos para el producto
- Se eliminen ítems cuyo valor ya no es relevante
- Se descompongan ítems grandes en otros más pequeños
- Se cambian las prioridades de los ítems, al reconsiderar su valor actual
Una idea central es que el Product Backlog es la única fuente de trabajo relativa al producto para el equipo. Sus ítems contienen todas las características, funcionalidades, mejoras, correcciones o extensiones que el producto necesite, y por lo tanto, todas se priorizan en conjunto, para ser desarrolladas por el mismo equipo ó equipos de producto.
Cuando un producto es muy grande, el esfuerzo puede distribuirse entre más de un equipo, con un único Product Backlog (y un único Product Owner), que representa la prioridad actual para el producto completo, en vez de prioridades parciales por componentes o áreas.
El Product Owner es el responsable por su contenido, visibilidad y priorización.
El Product Backlog sirve para responder a la pregunta "¿qué es lo próximo a desarrollar?" y aporta una restricción sana a la situación de que los Stakeholders siempre tendrán deseos aparentemente ilimitados para el producto, pero las organizaciones tiene recursos acotados.
Al hacer las prioridades transparentes para todos los involucrados, se habilita la discusión de cómo se distribuye el esfuerzo dentro de la capacidad disponible, siempre con la restricción adicional de la duración del Sprint.
Los ítems del Product Backlog (o PBI: Product Backlog Items) están ordenados entonces por su importancia en cada momento, y los más importantes suelen estar "refinados", es decir que ya están:
El Product Backlog sirve para responder a la pregunta "¿qué es lo próximo a desarrollar?" y aporta una restricción sana a la situación de que los Stakeholders siempre tendrán deseos aparentemente ilimitados para el producto, pero las organizaciones tiene recursos acotados.
Al hacer las prioridades transparentes para todos los involucrados, se habilita la discusión de cómo se distribuye el esfuerzo dentro de la capacidad disponible, siempre con la restricción adicional de la duración del Sprint.
Los ítems del Product Backlog (o PBI: Product Backlog Items) están ordenados entonces por su importancia en cada momento, y los más importantes suelen estar "refinados", es decir que ya están:
- Con su valor establecido (y ordenados en consecuencia)
- Divididos en los ítems más pequeño posibles
- Estimados (el equipo debe saber al menos que puede desarrollar varios en un Sprint)
- Detallados (suficiente como para que nada se bloquee en la Planning)
Los ítems que tienen menor prioridad (aún lejos de ser considerados en un Sprint o dos) pueden tener menos nivel de detalle, y aún no estar divididos en partes más pequeñas. Casualmente en Scrum diferimos estratégicamente esa tarea, para:
- Aprovechar todo el aprendizaje previo al momento de analizar un ítem, sobre todo el ver el incremento más reciente del producto, lo que influye muchísimo sobre próximas decisiones.
- Evitar analizar ítems que pueden variar (o desaparecer)
La actividad de agregar estos detalles al Product Backlog no es un "evento" sino una tarea permanente del Product Owner, llamada Product Backlog Refinement, que realiza colaborativamente junto a los Stakeholders y resto del Scrum Team.
Más allá de esa recomendación no hay ningún proceso ni límite de tiempo establecido, y cada equipo Scrum decide y mejora continuamente cómo realiza el refinamiento.
Es importante entender que los ítems que se refinan durante un Sprint no son los que ya están en el Sprint Backlog (y por ende, durante la Planning, se fueron del Product Backlog), sino los que siguen en prioridad, y pueden ser incluidos en el próximo Sprint (y un poco más, ya que no se puede predecir con exactitud lo que sucederá en la siguiente Planning).
También es importante, en mi opinión, que las actividades de Refinamiento no se conviertan en una Planning anticipada. Si se baja a demasiado detalle, sobre todo con el Development Team, estaríamos causando una sobrecarga cognitiva, ya que están trabajando en una serie de ítems (el Sprint Backlog actual) y no queremos distraerlos con detalles que pueden quedar para la Planning, cuando ya están liberados y listos para comenzar otro ciclo.
No hay comentarios:
Publicar un comentario