7 Product Backlog Tips to Make Work Flow

Ask ten agile teams how they do backlog refinement and you’ll likely get ten different answers. How you do this most unusual of agile processes depends on a bunch of variables: the tools you use, your team structure, the type of products you build, how long your sprints are, or the type of agile framework you use.

A lot of noise enters debates about backlog refinement because of these differences.

One article will recommend you to do backlog refinement weekly or once per sprint, while other folks tell you about the benefits of micro-refinement at the end of daily standups. All the while, agile purists have a habit of swooping in to tell you that sticking to any rules proves you’re just not agile enough.

Basically, everyone has a view on how to do backlog refinement, and there’s no single method that is right or wrong.

But there are some tips that can make your life easier and help your work flow.

This article covers 7 best practices for backlog refinement that can benefit your team no matter how you work together.

Agile methodologies are built upon the premise of self-organising teams. These kinds of teams are responsible for deciding among themselves how best to accomplish their work, rather than having it dictated from above by a manager

When the whole team adds backlog items, they’ve started on the road to self-organisation, because they have ownership for the parcels of work included in the product backlog.

The rationale behind getting everyone involved with the backlog has been proven. Academic research shows that when individuals have clear psychological ownership of a project or task, they perform better.

And not only that, because psychological ownership has been found to lead to greater commitment, self-esteem and job satisfaction, while lack of ownership can lead to the phenomenon of ‘bullshit jobs’. Teams that can add or suggest backlog items generally have more buy-in on the work they do and understand why they are necessary.

Giving everyone the power to work the backlog helps prevent traditional scenarios in which out of touch managers devise ‘pointless tasks’ for an increasingly frustrated workforce.

It also means that everyone’s perspective is considered and that you have more eyes on the lookout for important issues. For example, the Product Owner often is often in a poor vantage point to see pieces of technical debt that are holding the team back and should be reflected in the backlog.

You can think of a collaborative product backlog like your family shopping list.

To quote agile guru Mike Cohn:

Not only does this process create ownership, but it splits the work of adding items and results in a more rounded and complete backlog, factoring in multiple perspectives.

Not just the Product Owner’s.

While opening up the backlog helps build psychological ownership of work, there’s a risk that it also brings a whole lot of chaos. Particularly organised Product Owners may be tossing and turning at night as their brain conjures up nightmare scenarios of an ever-growing, messy backlog of monstrous proportions.

The whole process of backlog refinement (once known as grooming) is geared towards tidying, organising, and prioritising in a highly structured way.

Some Product Owners are understandably worried about opening up the backlog to everyone.

But there’s a right and wrong way to do it.

Creating a template for team members to complete when adding a backlog item means that:

We use a template in our backlog to ensure that items are sufficiently detailed before being submitted. This helps us get some consistency in how backlog items are structured and makes the process of adding an item a bit easier for everyone.

Here’s our pre-submission checklist. Folks must tick these items off before they submit a backlog item:

With a template like this, your Product Owner can sleep easy at night.

There’s plenty of debate about when and how often to do backlog refinement. We know that it’s meant to be an ongoing process that takes up no more than 10% of the development team’s capacity.

That means different agile teams find different refinement rhythms.

Some go for a weekly cadence while others prefer to refine before the sprint planning meeting. Newer teams sometimes like to do daily refinement to keep a close eye on the backlog and build shared understanding more quickly.

But whenever you do your backlog refinement, put it in the calendar!

Having a placeholder makes sure there is time set aside for the process.

So even if you get carried away with your work, the backlog doesn’t suffer.

Doing refinement ‘continuously’ may sound easy enough at the start of the sprint. But once you’re racing towards the sprint deadline, solving unexpected bugs along the way, it’s quite easy to forget about the backlog entirely.

That is until sprint planning comes around again.

Even if your team have a habit of regular refinement, there are some tasks that benefit from being scheduled and done synchronously.

Maybe your backlog is pretty well refined when that hour of calendar time comes around. So you can use that time to discuss cleaning out the backlog or use that time specifically for estimating effort together on more contentious items.

Scheduling time in the calendar, after your daily standups, first thing on a Monday morning, or at the end of your sprint puts aside a dedicated time for the backlog. You might not need it. But it’s always there in case you do.

When you go to the supermarket with your shopping list in hand you want to make sure the produce you’re buying is fresh. Most products have a best before date on them. Let’s say you’ve seen some tasty looking fruits in the store. You bring them home and put them in your pantry.

Only sometimes, those tasty fruits you bought get forgotten somewhere, buried under other produce. When you come to look in your pantry again, they’re not looking so tasty or healthy anymore. They’re already a week out of date and you didn’t even realise!

The purpose of this story is to show that it’s quite easy to add items to the backlog that feel fresh and exciting in the moment. But you may realise after adding an item that it’s not the right time, it doesn’t go with the theme of the current sprint, or there isn’t a huge appetite for it.

You may also suffer the guilt of seeing that backlog over and over again and not having the time to get to it.

These are the types of backlog items that often get deprioritised or even worse, forgotten.

Nobody likes cleaning the backlog of old and stale items, so why not let the robots take over?

We set up a bot that helps us with our backlog. Every time an item is more than 6 months old, with no further discussion or detail being added, our trusty robot helper lets us know. The item is marked as stale, and the team can discuss whether the item is still relevant or not.

If it’s a relevant item but now is not the right time, we do exactly what you would with your home produce – put it in the freezer. Our icebox is the place where we store all the projects that are going stale and aren’t ready to be worked on yet. Just like Walt Disney, we leave them frozen until we need to bring them back to life.

Here’s a sneak peek at what our trusty bot looks like in action:

If we can see that an item has already been resolved via another backlog item, is no longer relevant, or has no popular support, we simply close it. So it goes from the icebox into the trash.

We’ve also set up the bot to give us notifications in Slack, so we are all informed of what’s going stale on a daily basis. Now there’s a Microsoft Teams-GitHub integration, so you can also do the same if you’re running Office365. 

Whether you’re using Jira, GitHub, or something else, take advantage of bots to make your life that little bit easier.

After all, robots don’t have a sprint goal to meet, and you do!

They say old habits die hard. So I hope you can master this one. It will save you so much time and make your meetings more productive. 

Get into the habit of visiting the backlog on a regular basis, not just when your time-boxed refinement meeting comes around. While it might be difficult to master a daily practice, the Scrum Guide doesn’t call refinement an ‘ongoing process’ for nothing.

Keeping up with the backlog doesn’t have to be a time-consuming process. Simply setting up more robot helpers to integrate your backlog actions with your Microsoft Teams or Slack can help you stay up to date with what’s going on in backlog city.

This is especially handy if you’re a distributed team working across timezones.

Helping your team to add backlog as they come up and gradually adding detail as you go along will ensure that your backlog always reflects the latest information, no matter when you look at it in the sprint.

Here are some benefits of keeping your finger on the backlog’s pulse:

Some days there won’t be anything to add, but others may have included items that are worth taking a look at or contributing to.

Refining the backlog is a group effort and if you can put the work in during the sprint to shape up the backlog, you’ll have much more productive sprint planning meetings.

When you look at anything for too long, it’s easy to lose perspective. If you’re in a habit of regular refinement, your backlog meeting might be a good opportunity to break free and re-centre your perspective, using a more creative format, such as in-person or digital white-boarding.

By their very nature, backlog tools like Jira, Rally and GitHub are highly structured.

Everything is listed in priority order and inside each card are nested details.

Sometimes you just need to break free and be creative to get a new perspective on what’s in the backlog and what your priorities are.

Try using a whiteboard tool like Mural or Miro to enter a different headspace. Sometimes, rearranging and discussing user stories in a different physical or digital space can give you the clarity you need. Even an excel spreadsheet can give you more clarity over things like user stories.

Your whole process doesn’t have to revolve around one backlog tool.

Using whiteboard tools, or a reflecting, grouping, and voting tool like Parabol, helps you:

There are a bunch of different templates you can use to do this.

Darren, a Scrum Master and Kanban Coach based in Belfast, told Parabol that:

You can make the process simple by directly exporting the content of Parabol or whiteboard stickies, for example, to a tool like Jira. So don’t be afraid to work back to front: mapping and ideating in a whiteboard tool before transferring items to the backlog.

It’s easy to get overwhelmed and lose perspective when there are 100+ items on the backlog. Breaking away into different tools can restore clarity for the whole team and help you to ideate and prioritise better.

One mistake agile teams sometimes make is that they don’t estimate early enough. Early estimation is important because it helps you break down user stories into smaller units early in the process.

There’s a risk that teams may neglect the backlog until their refinement meeting – just before sprint planning.

During estimation there’s some divergence in opinion between team members. It turns out that one big user story needs to be split into 2-3 others 

Now you’re left with three non-detailed user stories with a vague estimation that ideally you should have been working on in the next sprint 
Early estimation helps to mitigate that situation and make sure all items are sufficiently small to be discrete user stories.

You can spice up your estimation a bit by using a mixture of techniques.

For example, the first pass, can be a broad estimation technique, such as t-shirt sizing. If everyone agrees on the size and an item doesn’t need to be broken down further, you can proceed to sprint poker to arrive at a more precise estimate and have a more refined discussion.

Initial t-shirt sizing estimation should give you a good idea of whether something needs to be broken down into smaller units. Those smaller units can then be detailed by the team properly before the next estimation session.

Building this time into the refinement process results in more accurate estimations and prevents reduced sprint velocity based on factors that could have been avoided.

When it comes down to it, backlog refinement can be a pretty controversial topic. There are countless interpretations of how to do it. And many tools to help you on your way.

There are also plenty of bad backlog refinement practices that can easily find their way into your work.

We know that every team has their own rhythm and backlog culture that they bring to the table. These recommendations should cross-cut all of those things and help your team work even better together, no matter your tools or process.

If you found these tips helpful, consider sharing them with your team!

Any awesome tips we should know about?

Let us know!

Want to read more about the product backlog?

Check out our related articles: