This article will help you get started with how to run backlog refinement; the art of making your product backlog ready for development!
- Not just a meeting. Backlog refinement is something you do throughout the sprint, which you can augment with refinement meetings.
- It is not a mandatory meeting in Scrum, but it is very useful (I recommend you hold a backlog refinement at least once per sprint)
- Required attendees: The development team and Product Owner review the product backlog together
- Keep each refinement meeting to no more than 1 hour; because it’s difficult to concentrate for much longer than that
- Reserve up to 10% of your current sprint time to refine the product backlog for future sprints
- The purpose of backlog refinement is to add detail, estimates, and order to items in the product backlog.
- The Development Team is responsible for all estimates i.e. the people doing the work are the people who provide the estimates.
Example Refinement Meeting
Keeping in mind that backlog refinement happens throughout the sprint, my teams hold two refinement meetings per two week sprint; one hour per week.
Both of our backlog refinement meetings are always time-boxed to 1 hour. So when we are planning each sprint, we know to leave 2 hours each sprint for these meetings.
💡 Top Tip
Schedule the meetings at the same time, same place, every week, so that you build a nice cadence and everyone can reserve the time in their calendars.
This helps the team stay in a state of flow at other times, maximising their performance knowing they won’t be interrupted for an ad-hoc refinement meeting.
Week 1 of sprint: First refinement meeting
The first refinement meeting is held a few days after we start the sprint, and we start to look at what might come into next sprint; the items at the top of the product backlog.
It’s very important that we start at the top of the backlog, this not only helps to ensure that the backlog is always up to date, but the items at top of the backlog require a lot more detail than those at the bottom of the backlog (which may never even happen).
We don’t want to spend time at the bottom of the backlog; those items will rise to the top over time, as they are required.
The first refinement meeting of the sprint is time for asking lots of questions. We might not be able to answer those questions straight away, but we can come back with answers a week later; in our second refinement meeting.
Having the first refinement meeting only a few days after the start of the sprint has a few benefits:
- It helps avoid meeting burnout. At the start of our sprint we’ve only just had Sprint Review, followed by Sprint Retrospective, followed by Sprint Planning.
- It gives us time to get started with the items we’ve planned this sprint. We may already have some immediate feedback from items we just started. This might inform the future backlog, and therefore items we need to refine as a team this sprint.
- Having the meeting early enough gives us time to generate the required questions, and gives us time to figure out the answers before the next refinement session. More importantly, we can answer those questions before we start the next sprint.
- In the first meeting, the team can decide what they will refine between now and the second refinement meeting; with enough gap to do the work.
Second refinement meeting
In the second refinement meeting, we should have answered all major questions, removed any blockers and be in a pretty good state for starting our next sprint in only a few days time. We should have a shared understanding of the product backlog.
By the end of the second refinement meeting, we understand the upcoming work, it’s split up into small enough chunks so that they can reasonably be completed next sprint, and we have ensured that the backlog items are ready to start.
Running the meetings
The Product Owner usually runs the meetings (facilitated by the Scrum Master). The team is informed (at least the day before) what sort of items are going to be discussed in the meeting. This gets people into the right headspace, with time to prepare and greatly improves the outcome of this meeting. Of course, they should be looking at the top of the backlog anyway.
The meeting starts by the Product Owner giving a brief overview of what’s going to be discussed, and goes through each product backlog item in order (starting at the top of the backlog); we ask the same set of questions for each item:
- Does everyone understand what we are doing here and why?
- Are there any outstanding questions surrounding this item that need to be resolved?
- Can we estimate this work?
- Do we need to split this work up so that it comfortably fits into a sprint?
- Is the order of work items correct? Do we need to adjust it?
At the end of backlog refinement, the items at the top of the backlog should be the most important, we understand why they are there, any impediments are flagged so that we can go away and resolve them, and all stories have an updated estimate.
At the end of our second refinement session, our backlog is ready to start the next sprint. It may be altered slightly by feedback from Sprint Review and Sprint Retrospective; but there should be no major surprises.
Top Tips to refine your backlog
1. Try to have at least two sprints worth of tickets refined at all times
Over time your team performance will improve (hopefully!), so having exactly one sprints worth of work refined will eventually have you come up short. For this reason, I try and ensure that my teams have two sprints worth of work refined at all times.
If we run out of work because we finish early or if something get blocked during development that can’t easily be resolved, then we have something ready to start.
Having two sprints worth of work ready, strikes a nice balance between refining too far ahead (and maybe never even starting the work), and running out of refined items (so potentially building the wrong thing).
2. Encourage the development team to refine the backlog in their own time
We shouldn’t only ever look at the backlog in the backlog refinement meeting, we should be looking at it in our own time. We should live and breathe the backlog as a team.
The Product Owner is responsible for ensuring that the backlog is ordered correctly, but the whole Scrum team is responsible for delivering an awesome product.
So we want the whole team to get deep into the backlog, digging into stories, splitting big pieces of work into smaller chunks, asking questions and truly understanding what’s going on.
3. Discuss your approach to backlog refinement in your next team retrospective
Are you unsure if your backlog refinement is going well? Take it to your next team retrospective. Use this article if you want 😛. Start by reviewing the purpose of the refinement meeting, inspect the top of your upcoming product backlog and ask yourself if it is ready to start next sprint. If it’s not up to scratch, what steps can you take as a team to improve that situation? Put that action item into your next sprint backlog and review if it worked in your next team retrospective.
4. Don’t refine too much
That’s right, a perfectly formed backlog is not what we are aiming for here. Backlog refinement is there to minimise the risk of an impediment in sprint planning. If you refine the entire backlog down to the smallest detail, you will find you’ve wasted time refining something that gets cancelled. Maybe there is a change in the market, or any other unforeseen circumstance that you don’t yet know about. With the time you save, you can actually build the product instead.
5. You don’t need the whole team for refinement
At some point you need to let the whole team know what’s going on, but to get started, you may find it useful for the Product Owner and a few team members to get together and refine a piece of work independently to the rest of the team. The results of these smaller meet ups will be fed back to the team in either your next group refinement session or at the very worst, sprint review / sprint planning.
I hope you found this article useful, and it helps you with your own backlog refinement! This is the way my teams do it, and how we’ve done it for years. It might not be perfect, but we have a great product backlog to work with at the start of every sprint! If you think anyone else would benefit, please share this article with them and comment below!
Till next time!