Skip to main content

Continuous Backlog Refinement

Reading: Continuous Backlog Refinement

Create your initial backlog, then stay on top of it. Here’s the how and why of Continuous Backlog Refinement.

In my previous article, I talked about compressed backlog refinement in which a backlog is taken from crude to well-groomed in a matter of days through a series of intensive refinement meetings with the whole team. The drawback, besides being several days of intensive meetings, is that we sometimes rush through some of the stories. We don’t have enough lead-time for other parties to do the work we depend on, and we don’t take a step back and look at the big picture. The pressure to get going causes us to not think clearly when looking for the minimum viable product of minimally marketable features.

In spite of its downsides, that approach may be necessary when you need to quickly refine an initial 1 to 3 month backlog and get a team sprinting. However, it’s not the best approach for refining and estimating additional user stories or subsequent backlogs. For that, we should employ continuous backlog refinement.


Most of my clients care about predictability:

For most companies we work with, the sweet spot is 3 to 6 months. If the product development organization can reasonably hit a 3 month commitment and have at least a high level idea of what things will look like 6 months out… that is something we can work with. — Mike Cottmeyer

It’s incredibly difficult to get a well refined backlog more than 3 months out using a compressed refinement approach. What I’m recommending, then, is planning ahead and staying ahead. Sure, if you need the compressed approach to get started, go ahead and refine that first 3 months of backlog. Then, immediately begin continuously refining the backlog for the 4-6 month time-frame.

Continuous Backlog Refinement

Here’s what this looks like: As stories are written, have someone else on the Product Owner Team such as a QA lead, tech lead, or analyst review and improve them. Bring those stories to the next backlog refinement meeting, which you’ll have each sprint. Call it backlog refinement, call it backlog grooming, call it story preview, call it story walk-through, call it what you will, but have it as a regular standing meeting on the calendar and invite the whole team.

Come into this meeting assuming you will need to update and split stories. However, don’t update them in the meeting. Team members can take to-dos to split and update stories after the meeting. Stories that undergo significant changes will go through the next backlog refinement meeting. Let’s keep this meeting short and do offline whatever we can.

Resist the urge to go into detail on any story. Just a few minutes or less is enough. Remember, we’re grooming stories that are 3 months out. We don’t need to spend much time on them now.

Assume the stories are not ready to be estimated. Assume development and QA might want to go do some research on the stories before they are estimated. Encourage them to do so. Give the team time to do so. Estimate these stories in a separate meeting. Refining stories and estimating them are different kinds of thinking. Estimate with some skill and care.

This approach keeps both refining and estimating meetings short, but means you may need a more detailed story walk-through at the start of sprint planning (the “what” part of sprint planning). Those who did the intensive compressed refinement meetings might be able to get by with a more abbreviated sprint planning meeting.


To get started with agile, when we have no backlog yet, we create and groom an initial backlog in a short period of time. We’ll call that compressed backlog refinement, and although it’s not the favored approach, sometimes you’ll just have to use that approach anyway.

Once the team is sprinting on your backlog, don’t let it dwindle down. You should have at least 2 or 3 sprints worth of well groomed stories, with acceptance criteria, ready for the team to implement. Most of the clients I work with need an additional 3 sprints worth of stories refined, but perhaps without the acceptance criteria. Stay on top of writing more stories and continuously refine your backlog.

Next Agile 2014 - Personal Kanban

Leave a comment

Your email address will not be published. Required fields are marked *