#29 How to Deliver a Backlog Refinement Session
Most engineering teams use Scrum or Kanban to track their work. Regardless of the approach, teams need to plan ahead for new projects or features that the business expects. One such activity is backlog refinement sessions. This is often led by a tech lead or senior IC, with input from the PM for product sense. In this post, I’ll share my strategy for running backlog refinement sessions effectively.
What is backlog refinement meeting?
It is a recurring meeting where the engineering team and the PM review the product backlog, add new or remove outdated tasks, and reprioritise for upcoming sprints.
Think of it like this: the input of the meeting is a list of unordered tasks, and the output is a priority queue where the sort key is importance score.
How to deliver a backlog refinement meeting?
Refinement sessions are typically led by Tech Leads (Senior or Staff). However, smaller projects or feature planning can also be led by Mid-level engineers, requiring efforts of ~1-2 engineers.
First, let’s clarify what the meeting should not be about.
⚠️ It is not a design proposal meeting.
If new projects require scoping and design for team buy-in, it’s better to have that as a separate meeting. The mechanics of the two meetings can be similar, but the outputs are quite different.
Design proposal meetings involve in-depth engineering discussions, exploring alternatives, and gathering feedback from the team. The next steps from this meeting could be either for the author to explore other options and check back (possibly with another design meeting if needed), or to reach a consensus on a specific design and start breaking it down into tasks (i.e. backlog refinement meeting).
Here are four steps for an effective session
For (operating) tech leads, your goal is to clearly communicate the tasks the team should focus on. A good way to prepare the agenda is by writing them down in advance, following this template.
Here’s the breakdown for each task:
I. Description: Context of the project: why this task exists and what we aim to achieve.
II. Technical Notes: Suggestions or ideas for implementation details the assignee should keep in mind. Links to existing designs or source code.
III. Acceptance Criteria (AC): When can we mark this as done? Have we tested this? Have we shipped this?
IV. Points/Days: How important is this task to the business? How many points or days should we estimate?
🌟 Tip: Product Managers highly appreciate this metric. It helps them manage expectations outside the team and also derive some clarity from the dev team.
V. Deadline (optional): Is this time-sensitive? Are users expecting it by a specific date?
Your agenda should look like this before the meeting:
How to run the meeting:
Set the context upfront.
If your team is working on multiple work-streams, specify upfront which type of work you want to refine. You might be refining work from two sub-projects or one highly important feature. Either way, make it clear at the start what you expect your team to review.
Walkthrough each task on the backlog.
Go through each task, explain its purpose at a high level (description), and what you expect the assignee to do (acceptance criteria). Highlight the technical notes (when applicable) and ensure that relevant resources are added for the assignee. Keep task descriptions short and concise as well as your explanation (~1-2 minutes).
Allow room for questions, modify if needed.
After going through each task, ask if the team has any questions. Leave some space for that uncomfortable silence before someone speaks up. This gives team members time to re-scan the task and call out any details. If there are questions or notes, make sure they’re resolved and added to the task if relevant (e.g., additional technical notes or a follow-up task).
Story-point and agree on estimates.
If everything is clear, ask the team for effort estimates (e.g., poker planning). This can reveal new insights, like some team members flagging risks by estimating high or everyone agrees this is a quick fix. Make sure each task the team reviews is story-pointed.
Note: You don’t have to use the “traditional agile estimation” holistically. An estimate can simply be 1/2 day or 1 day of engineering time. Follow your team’s preference for the estimates or metrics that work best for them.
Repeat steps 2-4 till the end of the session.
P.S. It’s okay if not all task are fully defined — as long as they include some details to guide the conversation and allow you to fill in missing details during the session.
P.P.S. Your team might work with more or less metadata on each backlog item. Use this as inspiration if you’re just starting out, and improve the template as you go.
Wrap up
Like anything else, getting good at delivering refinement sessions takes practice. Tech leads aren’t naturally skilled at it—they were once junior engineers who learned from their tech leads running these sessions, gradually took on feature planning with increasing complexity, and eventually became comfortable scoping and leading larger projects.
A sign of a growing engineer is one who proactively asks to scope a specific feature, understands the technical challenges, and can deliver a clear roadmap for technical delivery through well-refined backlog items. This approach of dry-run tech leading is a strong signal of someone operating at the next level.
For recap, the four steps are:
Set the context upfront.
Walk through each task on the backlog.
Allow room for questions and modify if needed.
Story-point and agree on estimates.
Rinse and repeat, and you’ll noticeably get better. 🚿
If you’re enjoying the newsletter, share it with a friend, and consider subscribing if you haven’t already. You can also add a testimonial through this 1-question form.
Here are some testimonials from our readers 🫶
