Backlog Refinement Without BS

What is backlog refinement?

Backlog refinement (previously known as backlog grooming) is the agile practice of reviewing, prioritizing, and refining the product backlog.

Think of an unrefined backlog as a messy closet. When your clothes are heaped and jumbled, it’s difficult to pick something to wear – or grasp the extent of what you own. But when you take time to review the items one by one, assess their value, toss what you no longer like/need, and neatly organize the rest, it’s much easier to find an outfit and get out the door on time.

Obviously, the stakes are higher in product development than in getting dressed, which is why backlog refinement isn’t just about staying organized. We do it to make sure the team works on tasks that add real value to the product e.g. enhance the user experience, create opportunities for revenue generation, or fix persistent bugs or issues.

Here are some of the tasks involved in refining a backlog:

• General review of each item (its requirements, relevance to current strategy, potential value).
• Merging duplicate or similar tickets.
• Splitting large stories/issues into smaller issues.
• Turning poorly-defined user stories or issues into actionable items.
• Contacting stakeholders (developers, designers, C-level execs, etc.) to get more information on certain items.
• Assessing timelines and tweaking estimates.
• Deleting issues that are no longer relevant.
• Prioritizing each item according to its value.

Backlog refinement vs sprint planning

The main difference between these two agile activities is that backlog refinement lays the groundwork for sprint planning. Depending on the size of the product team, backlog refinement sessions also tend to have fewer attendees. However, both are common agile practices and are part of the popular Scrum methodology.

How often should backlog refinement occur?

Aim to host a refinement session somewhere in the middle of a sprint (it needs to be completed before the next sprint begins, and out of the way of sprint reviews/retros, etc.). Make it a recurring meeting in your product team’s calendars, so that you always have ample time to analyze the list, generate new ideas, and gather relevant materials in advance.

How long should it take?

If you have fortnightly sprints and host bi-weekly refinement sessions, then your meeting shouldn’t run longer than 1 hour. This should be enough time to review the backlog and gather inputs from technical stakeholders – as long as you stick to the agenda. If you go longer than two weeks without refinement, then expect to dedicate more time to the meeting (2+ hours).

That said, preparing for a backlog refinement meeting takes work, and product managers/owners should set aside some time (an extra hour or so) during the sprint to prepare.

How to categorize backlog items

At Railsware, the backlog is typically shaped by our scope and product roadmap, as well as filtered customer requests, the input of technical stakeholders (bugs, security issues, etc.), and even insights drawn from our product dashboards. Due to the backlog’s size and complexity, we divide it into sections. This makes it easier for all stakeholders and meeting participants to assess, estimate, and prioritize the work. The categories include:

• Sprint drafts: a rough list of issues and tasks we already want to include in upcoming sprints, but are open to change.
• Buckets: items that have been categorized based on type. The main buckets are Bugs, Tech Debt, Product Management, and Security & Infrastructure.
• General backlog: a list of issues that either don’t fit into strict categories or haven’t been fleshed out properly yet.
• Icebox: ‘pipe dream’ items that we won’t get around to soon.

In terms of tools, our teams typically use Jira (for large projects) or Trello (for smaller projects) to manage the backlog and categorize items. For large projects, you can also use Jira templates, which can save you a lot of time by streamlining the creation of new issues by providing pre-defined fields and descriptions.

How to prepare for a backlog refinement session

We’ll get into the details of preparation in a moment, but first, let’s clarify: who actually owns the backlog refinement process?

In agile product development teams, backlog management and refinement are the responsibility of the product owner.

But for growing startups or smaller enterprises that don’t have large agile teams, it’s usually the product manager who takes ownership. In both cases, product managers are heavily involved in the process. They organize the meeting, set the agenda, gather information in advance, lead prioritization exercises, and provide expertise.

Review backlog items. Before the meeting, you should know what’s in the backlog and the context behind the most relevant items. You won’t have time during the meeting to discuss every item, so focus on something specific, such as the refinement of buckets (e.g. tech debt bucket).

Cross-check new/outdated items with the corresponding epic and more generally, the product roadmap. Does the item still seem relevant at first glance? Does it make sense within the context of the given epic? Make a note of these points and conduct industry research, consult with stakeholders, or refer back to the results of your customer development efforts. If necessary, take the opportunity to get in contact with relevant stakeholders (could be a customer success manager or a C-level executive) and clarify requirements.

Create a loose agenda to make sure the meeting stays on track. Consider the type of items in your backlog and how much time you’ll need to spend covering them. If there are some items you think you’ll spend more time on, account for this in the agenda.

Who attends the sessions?

As we touched on above, product managers and product owners are the main attendees of a backlog refinement session, alongside a few core members of the development team. It’s also a good idea to invite QA engineers so they can provide input on testing requirements and timelines for certain issues.

But we can’t say there is any fixed ‘guest list’ for backlog refinement. Who you should invite, and how many, really depends on the size of your product team and the complexity and maturity of your project. At Railsware, we manage multiple in-house and client projects, each at different stages of the product development lifecycle.

As a result, some product backlog refinement meetings only have about 4/5 attendees (product manager and a few key engineers) while others may have up to 10 (projects with larger dev teams, QAs, product designers, etc.)

Here’s an overview of who typically attends a backlog refinement meeting:

Backlog refinement best practices

Be consistent

It’s easy to fall into the habit of skipping backlog refinement sessions. These meetings often don’t seem essential, especially when everyone’s busy working on the current sprint. But the backlog will keep growing whether or not you’re closely monitoring it. Over time, it will get messier and more complex. And this disorganization eventually takes a toll on team productivity.

Again, we’d highly recommend making backlog refinement sessions a recurring meeting – same day, same hour, once per sprint. Think of it as a preventative activity that will save you (and the whole team) time and effort in the long run.

Collaborate and encourage feedback

Remember, backlog refinement isn’t about informing the dev team about which items will be pulled into the next sprint, or re-prioritized. It’s a collaborative activity.

QAs bring context to bugs logged during the last sprint and ideas for potential user stories. Product managers/owners help create more accurate estimates for timeboxing and can warn against overly-complex tasks that will eat into the budget. Meanwhile, engineers provide input on the technical feasibility of certain issues and help ensure that each item has well-defined acceptance criteria.

As we said, some agile teams use tactics like planning poker or story points to encourage participation and make estimating easier. But on the whole, productive sessions are built on good communication.

At Railsware, we strive to cultivate an open feedback culture where team members – no matter their seniority or role – feel comfortable sharing their opinion. It’s part of our holacratic approach to organizational management. You can check out our post on ‘How to Make Communication More Effective: Proven Techniques From a Product Manager’ for more on how to improve meeting efficiency and build trust within the cross-functional team.

Make sure it’s DEEP

It’s a classic piece of advice that covers all the essentials of backlog refinement and management. Developed by product management expert Roman Pichler, DEEP is an agile concept that stands for Detailed appropriately, Estimated, Emergent, and Prioritized. Here’s how it can be applied to the backlog:

Keep it focused

As much as it’s essential to gather feedback from team members during the call, try not to get sidelined by deep dives into complex backlog items. Remember, refinement meetings aren’t problem-solving or idea-generation sessions (at Railsware, we’ve got BRIDGeS for that).

You can always investigate issues after the meeting, by scheduling further syncs with knowledge holders (e.g. engineers who are specifically working on that epic) and/or by conducting your own research.

Also, it’s okay to keep the meeting timeboxed, even when you didn’t cover everything in the agenda. Do what you can within the hour, and then let the team move on. As long as the highest priority issues have been discussed and estimated, you can deal with the rest later.

Examples of backlog refinement

Let’s explore the backlog refinement process through the lens of two B2B SaaS products at different stages of the product lifecycle: a startup and a mature product.

Startup backlog refinement

Let’s imagine we’re the creators of Asana, and we’re building the MVP of the product. What would a typical backlog refinement session look like?

First of all, for most startups, the process is usually a bit chaotic. It’s more about cutting down the scope, time boxing, and investigating spikes. You don’t have a solid user base at this stage and you’re still trying to figure out what works. Meanwhile, your roadmap is more dynamic and only focuses on the near future.

In the early days of product development, epics tend to explode in size as new ideas and feedback are added. So to keep the team on track for an MVP release, it’s best to focus on refinement epics.

Let’s say for Asana, an MVP epic is ‘allow users to create tasks.’ As one of the application’s core features, this epic is bound to have dozens of issues attached to it, including performance improvements, possible expansions, fine-tuning, and bugs. The team can discuss and prioritize these issues during the refinement session (alongside other crucial epics) and decide what gets pulled into the next sprint.

All epics and issues that aren’t necessary to the MVP release can be deprioritized and tentatively added to the V2 backlog e.g. ‘app integrations’ feature. Once you get feedback on MVP, you can start refinement of the V2 list, and decide what’s relevant for the product you want to build.

Mature product backlog refinement

This time, let’s take one of our own products as an example. Smart Checklist is a Jira app that helps teams break down complex projects into smaller tasks. It’s already a few years old, has gone through several iterations, and has more than 2 million users.

Feedback loops and hypothesis testing have provided us with a solid understanding of our customer’s needs and preferences. Therefore, the roadmap is stable, and the entire process is far less chaotic than the startup environment we described above. Refinement sessions don’t focus on breaking down individual epics. They involve reviewing and prioritizing:

• Upcoming sprint stories.
• Customer requests logged by our customer support specialists and handpicked by the product manager.
• Product improvements that are part of the wider scope.
• Bugs and tech debt recently added to buckets by our QAs and engineers.

As we mentioned earlier, the team rarely has time to get all of these things done in a single meeting. And that’s okay. Unlike with an MVP, we don’t have to build fast. We can work on adding more value to the product through gradual UX improvements and careful selection of customer requests.

Prioritization techniques for backlog refinement

There are two main prioritization techniques that we use at Railsware: the MoSCoW method, which is our go-to across various departments, and the Kano Model, which we occasionally experiment with.

MoSCoW

The MoSCoW prioritization technique was created by product marketing specialist Dai Clegg in 1994. It’s a versatile framework that’s easy to understand and incorporate into your project management tool.

MoSCoW is an acronym for Must-have, Should-have, Could-have, and Won’t-have, each denoting a level of priority from high to low. Let’s discuss them using the Smart Checklist example:

Must-have: Issues that are critical for the success of the project and/or the upcoming sprint e.g. allow users to create custom rules and conditions for checklist templates.

Should-have: Issues that are important but not essential to the success of the project, at least in the near future e.g. make template visibility configurable.

Could-have: Issues that are desirable but again, not essential to the project’s success e.g. add a progress bar to checklists.

Won’t-have: Issues that are nice to have but can easily be deferred until more resources become available e.g. improve automation for Jira support.

Kano Model

In comparison to MoSCoW, the Kano prioritization model is more focused on understanding customer needs and expectations, rather than organizing project-critical tasks. It’s slightly less flexible, but can still easily be applied to any backlog.

The model has five categories: Must-have, One-dimensional, Attractive, Indifferent, and Reverse. Let’s use the Asana example again to demonstrate how they can be applied.

Must-have: Requirements that are crucial for the success of the project, based on customers expectations e.g. users can view workflows in Gantt chart format.

One-dimensional: Performance-based issues that directly impact the user experience, and thus need to be dealt with swiftly e.g. a bug that causes the goal-setting feature to crash.

Attractive: Issues related to innovative improvements or additions that will delight the customer e.g. an analytics dashboard feature, where customers can get insights on their workflows.

Indifferent: Issues that are not critical to the success of the project. Customers won’t notice these items are missing from the product e.g. making user interface themes customizable.

Reverse: Issues that seemed like good ideas at the time they were added, but after review, don’t appear promising e.g. an action that adds more complexity to setting up a workflow.

We also discuss alternative prioritization techniques in our post ‘How to Prioritize Product Features.’

What is the ideal outcome of backlog refinement?

As we’ve already mentioned, the most important outcome of backlog refinement is for the backlog to be up-to-date and relevant to the current product strategy and sprint activities.

A refined backlog helps us allocate resources to the right activity, thus reducing the risk of technical debt and keeping our product roadmap in check. The prioritization exercise also makes it easier to choose which issues should be worked on during the next sprint.

What if you don’t run (regular) refinement sessions?

Having a disorganized, unprioritized backlog doesn’t mean that you won’t get work done. But it does increase the chances that you won’t get the right work done. And for startups with limited resources and capital, this isn’t something to ignore.

Backlog hygiene is a key element of Lean software development because it aligns with the concepts of eliminating waste and delivering value to customers. Basically, it lets us weed out the tasks that aren’t essential to our immediate product goals and focus on work that guides us toward a product-market fit.

If you’re not regularly refining the backlog it’s easy for the team to start working on issues that seem valuable or exciting, without considering the long-term repercussions.

For example, let’s say a few of your backlog items involve adding an AI-powered chatbot to the product onboarding process. It might sound like a great idea, and once implemented, actually help you increase user retention. But if another set of items in the backlog revolves around implementing a payment processing system – so you can start monetizing the product – it’s clear which ones should be pulled into the upcoming sprint(s).

Wrapping up

Backlog refinement is vital for keeping the team productive and ensuring they work on high-value tasks. It’s not always easy and requires a good bit of preparation. But when you commit to regularly reviewing your backlog and involving key members of your team in the process, it becomes less of a nuisance. Prioritization is an important element, and shouldn’t be skipped. By following best practices and tailoring the process to fit your team’s size, stakeholders, and approaches, you can turn backlog refinement into an efficient and painless activity.