Program Backlog Refinement
Activity: For the highest-priority PBIs (which are usually epics and features), ...
Review their alignment with the executive vision and strategy.
Identify enablers required by NFRs or technical capabilities, and add them to the backlog. (For this reason, it is important that the architects and technical leads participate in backlog refinement.)
Split them into INVEST-able stories that are small enough to fit within iterations.
Refine their acceptance criteria.
Estimate them. (Product Owners may need reach out to their teams for input.)
Attendees: Release Train Engineer (facilitator), product management, solution and system architects.
Cadence: Every program increment, before the planning meeting.
Approximate time: The work happens--not just in one meeting--but throughout the program increment, or at the very least in the IP sprint. Schedule meetings, as needed.
Inputs
Prioritized program backlog.
Executive vision and strategy.
Outputs
Program backlog (including enablers) with highest priority items estimated and sprint-sized.
Next up: Program Increment Planning.
Program Backlog refinement is a regular workshop in which the content owners (e.g., product manager, product owner and stakeholders) and technical authority (e.g., technical owner, technical lead, architect, or team) review the prioritized backlog and prepare it for the upcoming, relevant increment planning meeting. It occurs both in single-team Scrum led by the chief product owner).
As a result of the meeting, the highest priority items on the backlog are (1) aligned with any vision, strategy, and/or release goals; (2) split to make them INVEST-able; (3) reviewed for correct and complete acceptance criteria and (4) given estimates (story points). The output of this meeting (the refined backlog) is the input for the relevant increment planning meeting, and should be completed at least two days before it in order to allow the content owner time to revise priorities, if needed.
Also known as backlog grooming, refinement of the backlog must occur regularly to ensure that the backlog items remain relevant and prioritized. Backlog refinement can be an officially scheduled or an ongoing activity.
Goals:
Remove backlog items that are no longer relevant.
Create new backlog items in response to newly discovered needs.
Re-assess the relative priority of backlog items.
For the highest-priority backlog items,
Align items with vision, strategy, and/or release goal.
Ensure that they have clear acceptable criteria.
Assign estimates (or correct estimates in light of new information).
Split items which are too coarse-grained to fit into a sprint.
Scrum: Product Backlog Refinement
Activity: Split highest-priority PBIs into INVEST-able, sprint-sized stories, refine their acceptance criteria, and estimate them.
Attendees: Product Owner (lead), agile team, and any needed Subject Matter Experts (SMEs).
Cadence: Every sprint, before the planning meeting.
Approximate time: This is an ongoing activity, owned by the product owner, with a final meeting which usually takes 2 hours.
Note: A single team sprinting as part of a scaled agile implementation will not need this meeting. They will work from the team's PI board rather than a product backlog. See program backlog refinement, below.
Inputs
Prioritized product backlog.
Outputs
Product backlog in which the highest priority stories have been ranked, given clear acceptance criteria, and estimated, and are sprint-sized. There should one-and-a-half to two sprints worth of these high-priority, refined stories.
Next up: Sprint Planning.