Your product backlog is a bit like a garden. When it’s well cared for, it allows beautiful things to grow. But left unattended it turns into an overgrown mess of weeds. Backlog refinement is the process of pruning, thinning, weeding and propping the plants in your garden - eventually allowing you to harvest some great features.
Why Backlog Refinement
It’s easy to let a backlog get out of hand. There’s no end to ideas for new features and improvements. However, if your backlog is unrefined, you’ll find your work as Product Manager to be more difficult and less efficient. You’ll struggle to keep track of what’s in the backlog, and time at backlog refinement meetings – and even sprint meetings – will be wasted examining stories that aren’t ready. Even worse, you may fail to prioritize the features that are of most value to your customers.
A refinement process that is regular, ongoing and standardized will help keep your backlog short and actionable.
Keeping Your Jira Backlog Refined
Having a well-kept backlog starts with removing the weeds. You’ll want to check to make sure each issue is still relevant. Does it fit with your product roadmap? Has it been made irrelevant by another feature? Do you have duplicates issues for the same items?
Once you’ve removed inappropriate issues from your backlog, it’s time to develop your user stories. Good stories are collaborative. Include product owners, scrum masters and developers in your backlog refinement meeting. It can also be useful to include a member of your support team to ensure that customer insights are fully understood. Having multiple perspectives ensures that stories in your backlog will be in line with your roadmap (product owner), valuable to your customers (support team member) and technically doable (development team).
What is Your Definition of Ready?
How do you know when a user story is ready? This is where a checklist can help. You can create a checklist template that captures your “Definition of Ready” and set it to be automatically added to all stories in your backlog. The checklist could include items such as “Has no dependencies,” or “Has defined acceptance criteria."
Many Product Managers use the INVEST method to ensure that user stories are ready to be included in a sprint:
- Independent — the user stories can be developed in any order
- Negotiable — the team can negotiate the scope
- Valuable – the fix/feature brings value to the customer
- Estimable – the development team can estimate the time/story points needed
- Small — the work fits into a single sprint (If a user story is too big for a single sprint, break it up into smaller pieces.)
- Testable – anyone with context knowledge can perform unit and acceptance testing.
Along with standardizing user stories, using a checklist adds visibility. It’s easy to see what needs to be done to make a story ready, and which stories can’t be made ready (in which case you may want to drop them from the backlog).
Simple tools, be it a trowel for your garden or a checklist for your backlog, endure for a reason. The small act of adding a checklist to your issues gives Product Managers the information they need to prioritize stories and teams the information they need to build them.
