Place Your Order: Prioritising the Product Backlog
Whether you realise it or not, prioritisation is a soft skill you use every day. You do it at work, where you have a never-ending list of tasks to do; in games, whenever you set out to grind for experience points; and even at home, when you go through your list of chores to do. However, we won’t drill down into the tips and tricks of how to prioritise your entire life — there’s a truckload of other articles out there that deal with that.
As a brief introduction, I’m Olivia, a Project Manager at Mighty Bear Games. I’ve been in the Games Industry for a relatively short period of time (starting on my 3rd year!) but I have been dealing with issues like prioritisation — and sometimes, maybe more — on a daily basis, since the start of my career close to 8 years ago.
Now with the introduction out of the way, let’s get down to business.
Today, we’ll sit down and talk about how to prioritise one of the things most Project Managers and Product Owners have to deal with every day — your Product Backlog.
Regardless of the production tools being used (we use Trello boards and comprehensive Google Sheets!), the guidelines we are about to outline below will help navigate you through your prioritisation exercises on the Product Backlog with your team.
Wait a minute, what’s a Product Backlog?
According to Scrum.org, a product backlog is an ordered list of everything that is known to be needed in the product. In usual practice, the Product Owner is responsible for the Product Backlog in terms of the content and its priority — what features go into the product first, what fixes need to be done, etc.
Why is it so darn important to keep the Product Backlog prioritised??
It’s important to remember that the Product Backlog is dynamic. Its contents can change throughout the development of the product from both internal and external factors, and it’s extremely important to ensure it’s ALWAYS prioritised.
Here are some reasons why:
- Bigger, clearer picture of your product: It’s super easy for your Product Backlog to turn into a dumping ground of ideas, feature requests, bugs, crash fixes, or a myriad of tasks. In a sea of clutter, it’s hard for you to get the big picture of what your product is going to look like — you could very well miss a critical feature that needs to go in asap.
- It gives focus to your team members: People always know what to tackle first and they can go through the list knowing and being assured that what they are focusing on is relevant for the product. As a bonus, if some of your team members are done with their work for the sprint and have some bandwidth, they can go into the prioritised backlog and start working on the next unassigned task that’s relevant for them — without needing any guidance!
- Work doesn’t go to waste: If the list is un-prioritised, people might be developing features that they feel are important to them, but in reality, it’s not critical and should have been last to go in. For all you know, that feature they were working so hard on could be cut later on in the development cycle!
This list could go on and on but let’s cut to the chase and I’ll show you how we do it the Mighty Bear way!
A BEAR-Y GOOD GUIDE TO PRIORITISING YOUR PRODUCT BACKLOG
STEP 1 — Go full-on Marie Kondo.
Declutter Your Backlog!
You need to do a quick assessment of your backlog and see if any of the items are obsolete. If they do not spark joy, and you know for sure that they will not make it into the product, remove them. If they are already completed, shift them out and record them someplace else!
STEP 2 — The “Bucket” List
Use a methodology to measure each of the items on the backlog and bucket them into categories.
There are various methods of measuring each of the items in the backlog and bucketing them. At our studio, we assess the Impact and the Complexity of the task. This is an exercise that needs to be done with the lead of each department — Product Owner, Project Manager, Lead Designer, Art Lead, Tech Lead, etc.
- IMPACT: It’s important to know what kind of value the task or feature will bring to the table. Will this future-proof our product? Is it a user retention feature? Does it improve adoption rates significantly? Also, the impact of the task or feature could change depending on what you and your team have set as your objectives for the milestone. Measuring impact can be a whole new article on its own but we won’t go into that here.
- COMPLEXITY: It’s important to understand the effort level and amount of time that will go into each feature or task. For this, you need to get input from your development team when you measure your backlog.
From there, we put it on the Impact vs Complexity matrix according to the picture below.
STEP 3: Absolute Values
Stack rank your backlog!
Once you have a sense of your buckets, you should be in a good position to stack rank your backlog.
Here’s how to stack rank your backlog:
- Every item in the backlog is assigned a priority — 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 and so on all the way down to the 500th item.
- No two items should have the same priority. It defeats the purpose of the exercise. Fight the urge to assign two items with “Priority #1”, I know you can do it.
And that’s it! Once you have followed these steps, you’ll have yourself a prioritised Product Backlog!
I hope this article was useful for you — leave some claps or a comment below! I’ll be writing more articles on productivity and time-management so stay tuned. Till next time!
