Scaled Professional Scrum and Nexus – Product Backlog Refinement

The Product Backlog Refinement event in the Nexus framework is the scaled version of the Product Backlog Refinement pseudo event from the Scrum Framework.

How does it work?

Product Backlog refinement is not a mandated part of the Scrum framework. This is because some Scrum Teams do not require a formal event to do this work. This may be because it can be completed informally or carried out during the Sprint Planning event. At scale, Product Backlog Refinement is essential and so is a mandated part of the Nexus framework.

During Product Backlog Refinement, Product Backlog items will be decomposed into small enough units, with enough detail that they can be planned and delivered in future Sprints. Dependencies will be identified, understood, made transparent and eliminated where possible.

This advantages Product Backlog Refinement offer are:

  • Allows Scrum Teams to identify dependencies between Product Backlog items as early as possible and seek to reduce them so individual Scrum Teams can work more independently during Sprints.
  • Helps to reduce big batches or work and reduce complexity by breaking large pieces of functionality down into smaller more manageable units. This helps with the creation and testing of new features and increases the probability of a Scrum Team achieving a done Increment by the end of their Sprint.
  • Allows Scrum team members time to explore and understand upcoming Product Backlog items in advance of the Sprint in which they will be implemented.
  • Facilitates the input of multiple Scrum teams into the exploration, detailing and estimating of each Product Backlog Item. This helps ensure a greater understanding of the work required to deliver the item at a later date.
  • Allows external Subject Matter Experts to get involved and and offer assistance in planning and design ahead of implementation.
  • Allows the Scrum Teams to guide the Product Owner in the efficient ordering of the Product Backlog.
  • Used to plan and forecast which Development Team may deliver a given Product Backlog Item in a future Sprint.

Who should attend?

  • Product Owner – May be supported by Product specialists that are helping them perform their role in a scaled environment.
  • Scrum Team members – It is likely that as we are now operating at scale it will not be practical to have all Development Team members from every team present during this event. Therefore the Scrum Teams will self organise to decide who is the right person or people to attend this event. As with all things in Scrum, inspection and adaption may lead to the attendees to this event changing over time.
  • Scrum Master – As requested or required to facilitate this event.

What is the time box?

The Nexus framework suggests that the duration of Nexus events be guided by the length of the corresponding events in the Scrum framework. So for Product Backlog Refinement the suggestion (not mandated) is up to 10% of the capacity of a Scrum Team during a Sprint.

Inspection and adaption may lead to this being adjusted over time as required. At scale, the number, frequency, duration and attendance of Product Backlog Refinement events is based on the dependencies inherent in the Product Backlog. The greater the complexity and dependencies, the more the Product Backlog items must be refined to remove them.

Enough Refinement meetings have been performed during a Sprint if the Product Backlog items are ready and selectable with minimal dependencies during the Sprint Planning meeting.

When and where does it take place?

It is a good practice to hold Product Backlog Refinement events at regular times and at a consistent location during a Sprint. This helps ensure attendees have a clear expectation of when and where they need to attend.

What else do I need to know?

Only when the Product Backlog items are sufficiently independent can they be selected and worked on without excessive overlap and dependencies between Scrum Teams in a Nexus. As such, Product Backlog Refinement a vital event that must be carried out successfully in order for a Nexus to perform effectively.

Next post: Nexus Sprint Planning –>

<– Previous post: The Nexus Integration Team

Index – Scaled Professional Scrum And Nexus – The Definitive Guide

Share this Post

Comments 1

Leave a Reply

Your e-mail address will not be published. Required fields are marked *