Backlog Refinement Agenda/Guideline

Purpose of Product Backlog Refinement:

The purpose of a backlog refinement event is to collaboratively review and prepare backlog items to ensure they are well-defined and ready for inclusion in future sprints.
The scope of backlog refinement is to consistently maintain a minimum of two sprints worth of stories in a state of readiness for future work. This allows the team to have a ready supply of work to pull in at any given time should priorities shift, which they often do.

Time-box: 1-2 hours (Backlog Refinement activities in the Sprint should be continuous and as needed)

Scrum Lead:

Introduce the agenda.
Clarifies the scope of the meeting. (Ideally, a team should not be refining more user stories than it can handle within the next two or three sprints. Otherwise, the risk of allocating resources to user stories that may never make it into a sprint backlog becomes too high.)
Identify meeting note-taker
Clarifies the rationale and the key points of the meeting.
Indicates the agreed-upon time box for the refinement session.
Indicates the time box likely required for discussing each Product Backlog item to complete Sufficient Product Backlog items in the key meeting.

Product Owner (PO):

Presents ideas and the likely vision for the upcoming Sprints.
Identify the desired sprint goal in collaboration with the developers
Introduces the Product Backlog items (already prioritized and ranked) and their acceptance Criteria

Developers:

Applies the 3Cs (Card or Story, Conversation, Confirmation (definition of ready)):

Discuss the Minimal Viable Product(s) inherent in Product Backlog items with the PO. (A minimal viable product is a version of a product with just enough features to satisfy early customers and provide feedback for future product development.)
Estimates effort for each of the Product Backlog items.
Discusses any points of divergence to the estimate of effort for each Product Backlog items
Break down the Product Backlog items into smaller pieces through collaboration with the PO to ensure that each item can be committed to for completion within a single Sprint. This helps the team remove any unevenness that can increase wasted time and effort due to context switching.
Communicate to the PO any consequence relating to what is being asked for and its rank order for delivery, including any technical, design, or business debt that may be incurred.
Based on the team’s shared understanding of the Definition of Ready, confirm that the story meets that Definition. (See the sample checklist for a definition of Ready below.)

Backlog Refinement Checklist (The Definition of Ready):

User Story Lay-out: Who, What, Why Defined from the user’s perspective?
Clear and Well-Defined: Work items should be clear, concise, and actionable
Acceptance Criteria: Acceptance Criteria is clear, and all team members are aligned
Priority and Value: Work Items are prioritized with the most urgent work item to be worked on first by the team
I.N.V.E.S.T:
- Independent: Any dependencies are identified and addressed, ensuring that the team can work on the item without impediments.
- Negotiable: Stories should be open to negotiation and discussion between the developers and the PO. They should not be overly detailed or rigid, allowing for collaboration.
- Valuable: Each story should have value for the customer or end-user. It should address a specific need or provide a clear benefit.
- Estimated: The developer has estimated the size and effort required for each story, which is important for planning and prioritization.
- Small: Stories are small enough to be completed in one sprint, ideally representing a single piece of functionality. The Smaller, the better.
- Testable: The team can easily verify the work against the defined acceptance criteria through testing.
Agreement: The developers and PO have discussed and agreed upon the item, and they share an understanding that it meets all the above definitions of ready.

Scrum Lead

Encourages all developers to participate in the estimation exercise, ensuring democracy and confidentiality (The Planning Poker helps us stay confidential and democratic PlanningPoker.com – Estimates Made Easy. Sprints Made Simple.
Encourages participants to use established Patterns to break down work items.
Encourages participants to create granularity that ensures the top 20% of the Product Backlog contains fine-grained work items.

SMEs and other interested stakeholders

Observe.
May participate in the discussion of the “Sprint Goal” through prior negotiation with the Scrum lead and the PO to assist with increasing transparency of upcoming Products.

To learn more about the Agile ways of working, join our upcoming training, mentorship, and apprenticeship cohorts.