Backlog refinement: before, during and after

Planning block. Session 1

It is a process of reviewing BLs and selecting stories for future sprints.

Key thing to focus on during Refinement:
- ask questions / clarify each story
- estimate story points / time (size of a story can be based on Fibonacci numbers: 0,1,2,3,5,8,13..)
Length: between 45 minutes to 1 hour
Regularity: once in a sprint cycle
Participants: PO and related to epic / stories stakeholders

Before the Backlog refinement meeting must have

1. The User stories are ready and prioritised (based on product vision / goal)
2. Demand-based plan for next sprint

ProTip: Select the scope (2–3 for each developer) and go through it

3. Definition of Ready & Acceptance criteria

During the refinement

1. Open up each user story and go through: Acceptance criteria, Wireframe, Business logic etc
2. Address Engineering questions on XF Dependencies, doubts, requirements
3. Adjust if breaking down required (use INVEST framework)

User story unit characteristics

4. Be ready to put something on hold if uncertainties arise (Spike)

Use the tool https://planningpokeronline.com/ for story points estimation exercise in a group.

After the Refinement

1. Send minutes of meetings (list of Stories)
2. Backlog Health report:

• all refined user stories (acceptance criteria)
• dependencies (UX wireframes, APIs..)
• anything requiring clarification

First example:

1. Started with the brief of the project
2. Listed Epics. First epic is New account creation

It has 6 user stories within it.

Jira log of the story

After the whole team gone through the stories with
- clarifications & questions
- adding some criteria in and taking some off
- moved to later to “clarify from stakeholders”
The group was broken down into pizza teams to grinder into sub-tasks and estimate the time. This user story required 24 hours i.e. 3 days.

Backlog refinement in Product Cycle

Second example

An Epic: New account creation

User story: As a regular user of a mental health app, I want to contact customer support team to get my issue addressed.

Acceptance criteria:

1. A user can sign in to the mobile app
2. The user can navigate to the contact / support page
3. The user can choose between call, chat or email options to receive support (available 24*7 for emergency)
4. The user can get their simple issues addressed via chat bot
5. A user can contact the support via call
6. A user is able to request a call if waiting time is too long
7. A user can opt in to request a callback
8. A user can leave a feedback of their support after being in contact with them (another Epic)
9. Language options (future sprints)

A child issue:

1. Track the status [4 hours]
2. User verification (DoB, address) [6]
3. Validate the issue (for existing ticket or possible dependencies) [8]
4. Log the callback status / request with any details [10]
5. Define and implement RESOLVED status [4]
6. Implement CANCELLED status for service request [4]

A question to readers or for my own further research:

- Can this be the only prioritisation you do +new batch from feedback loop?
- How do I size the impact so it’s generally accepted practice?

Credit: ScrumGuide