Helpful techniques for backlog refinement

Over the course of my career, I’ve had the opportunity to work with several different teams. Through all of those experiences, I learned that there are no best practices, but there are a few techniques that I’ve found helpful in just about every situation to figure out the best way to work with any given team.

These techniques assume your team follows an iterative approach where you split work down into small, testable increments. If in addition you’re working in a fairly complicated environment you’ll find it helpful to describe your backlog items shortly before your team starts to develop and test them.

April Podcast Tour

In the last week or so I appeared on a couple different podcasts to provide to chat about a couple of topics related to product development.

How product management can help teams tackle Tech Debt

I joined Arin Sime on his Scaling Tech podcast to have a wide ranging discussion with Arin and Lou Franco about how product teams can work together to tackle tech debt.

Keeping backlogs lean with a Now-Next-Later Roadmap

In response to a comment I made in SubStack notes about why I use backlogs, Vasco Duarte asked me to stop by his Scrum Master Tools Podcast to chat about it.

Definition of Ready

When I start work with a team, I make it a point to sit down with the team and have a conversation about what kind of information they find helpful to start working on a backlog item.

The output of that discussion is often referred to as a definition of ready. It’s effectively an agreement on the information about a backlog item your team finds helpful to build that portion of your solution.

The part of the technique I want to focus on for this discussion is the way I structure the conversation.

1. Gather your team together at a whiteboard (be it physical or virtual). Explain that the purpose of the discussion is to establish an agreement on what they find helpful to know about a backlog items.

2. Have the team generate a list of all the things that would be nice to have identified about a particular backlog item prior to building and testing that portion of your solution.

3. Once the energy for adding new items seems to die down, go back and review the list.

4. Ask the team to consider whether it’s reasonable to expect to know all of the items they suggested for every backlog item.

5. Continue revising the list until the team feels comfortable with the resulting items, which will generally be fewer than what the team originally identified.

This list forms the team’s definition of ready.

You can use that list of items as an ongoing checklist to determine what information you use to describe your backlog items.

Remember it’s a guide, not laws written in stone. Use your judgment regarding what information is appropriate for specific backlog items. Also, it’s good to revisit the list on a regular basis to make sure the information you’re pulling together meets your teams needs.

Describing backlog items

I feel as though over the past few weeks, I’ve hammered this topic quite a bit.

In I do use backlogs. I don’t write user stories, I explained why I use the term backlog item and don’t use “As A, I Want, So That”

In How to maintain a manageable backlog, I explained the rough outline I currently use to describe backlog items. I arrived that that outline based on discussions I’ve had with the last couple of product teams I worked with.

As a quick recap, that outline is:

Overview: Provides the context for the backlog item and identifies the problem

Revisions Needed: where I describe the solution (this is where the level of detail can vary widely from team to team)

Business Rules (when needed): if a backlog item is implementing some business logic (for example, pricing calculation) I’ll pull those out separately

Acceptance Criteria: A set of criteria that explain things that need to be true in order for the backlog item to be considered complete.

Examples (when needed): If we need specific examples to confirm the acceptance criteria, I’ll note them here. Using real data and situations whenever possible.

And in Practical advice about backlog items and outcomes, I explained how I name backlog items and try, but don’t get hung up, on having them reference outcomes.

The main thing I need to add to those discussions is a suggestion about when you note things as part of a backlog item itself, or when you link out a different artifact.

That discussion comes down the difference between project documentation and system documentation.

Project documentation describes a specific change and assumes a particular starting point. It’s only relevant for a certain point in time, and is best recorded in the backlog item itself – usually in the Revisions Needed section of the outline.

As an example, we recently revised the layout of the checkout page of the websites we currently work on. The information in the corresponding backlog item is only relevant assuming a given starting point (the current layout of the checkout page). It’s not something we’d need to refer to later on, except to know when we made the change.

System documentation is information that is relevant on an ongoing basis. If you think you have something that you’d like to refer to on an ongoing basis you probably have system documentation and should put it in a separate artifact rather than burying it in a backlog item.

As an example, we have separate API specs for each API in my current product. I keep the specs in separate documents and update them whenever we make a change to the API. It’s helpful to have these separate documents organized by API so we can find that reference information faster than if we had to hunt through a bunch of backlog items.

Other types of system documentation may include data dictionaries, customer journeys, business rules, and configuration data. For the last one, the “system documentation” for the configuration data may be the the database or json files where you maintain that data.

You want to know where to find that information so you can look it up quickly, but you also don’t want to duplicate the information if you don’t have to.

Refinement Board

The third technique is a way to visualize how backlog items progress through your refinement process – the refinement board.

If you’ve used any of the most common backlog management tools – Azure Dev Ops, Trello, Jira, or Clickup for example – you’ve probably used a delivery board to track the development and testing progress of backlog items.

The refinement board does the same thing, but tracks the state of backlog items as you get them ready to develop and test.

You may find a refinement board helpful to get visibility into the state of your team’s backlog. It also shows how many backlog items are ready for your team to start development and testing.

If you follow an iterative approach (such as Scrum), the refinement board provides your team an idea of which backlog items you’ll discuss during estimating sessions and which backlog items you’ll fleshed out next. This helps your team hold much more effective iteration planning sessions.

The refinement board also provides a visual aid when you talk to your stakeholders about difficulties you may be having with the backlog, such as too many backlog items coming in with insufficient information or not enough valuable backlog items to work on.

What are your backlog tips?

Those are some techniques I’ve found helpful based on my experiences. I’d love to hear what backlog tips you have from your experiences. Hit reply if you’re reading this as an email, or leave a comment if you’re reading in the Substack app.

Thanks for reading

Thanks again for reading InsideProduct.

If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, let me know.

Talk to you next time,

Kent