Handy tips to organize the big marathon and start cleaning your product backlog right now!
As a Scrum Product Owner, I am responsible for keeping a neatly ordered and cleaned product backlog. I am sure that you’ve read the Scrum guide and you know what this entails. I´m not going to get into specifics as I assume that you have the fundamental knowledge of Scrum and the product backlog as an artefact.
Let me tell you a story. Forget about the theory for a moment, you´ll learn how to deal with a bloated product backlog if you land on a new role and you inherit an enormous backlog which you should manage, order and defend 🙂 Good luck if you leave it all to the chance 🙂
This happened to me, I landed in an awesome team, but inherited a product backlog was a big chaos of technical tasks with no priority, old product ideas by a product owner, quick notes, anything you can imagine. Some tasks were even in a different language 😀 and not in English. Some items had just a title which I couldn´t understand anything about and were created by former employees (some who I´ve never met).
Now let’s face it, you cannot advance and do quality product work with a messy backlog which continues accumulating fancy ideas and good user stories for implementation.
You cannot advance and do quality product work with a messy backlog which continues growing in all directions over time.
What Santa´s long wishlist and your product backlog have in common? Some stakeholders think that the product backlog is where every single idea should go in order not to be forgotten!
WRONG! I´m heartbroken every time I hear this. That’s OK, remember that your role is to be a product ambassador, defend your product and its goals, so this implies product education and coaching where necessary.
I’d love to clear the air, so allow me to summarize some misconceptions which you can learn from, reuse and explain them in a way which even your granny will understand.
What is a Product Backlog?
The Product backlog is one of the essential elements in Scrum. It includes all the business critical elements which you’ve identified to develop a software product.
The backlog includes things which specifically pertain to the product development and evolution and the list is based on priorities. The elements which the backlog is composed of are called PBI, product backlog items.
What is a Product Roadmap?
The product roadmap is a structured approach to organize your main implementation buckets / themes over time. It is closely related to the product vision and your product strategy. If you don’t have a product vision, do me a favor, make sure you understand the product which you will be managing and work on crafting your product vision.
The lack of a common and inspiring product vision which shows the big picture of where you want to be is the culprit for the messy Product Backlog. A lack of a common vision between the Product Owner, the stakeholders and the Development team is the biggest mistake which will continue dragging you down. Evaluate the ideas based on the vision and create the backlog items only for valuable things that help the product reach the vision.
The product roadmap provides a strategic product direction for the next Q or 1 year. It is a tool which enables you to partner with stakeholders and the development team to define, deliver and advance the product evolution.
Why do I need a product backlog then?
The product backlog translates your product roadmap into manageable implementation chunks. Note that I´m saying implementation, because it covers both the UX/UI work and the development itself.
Each item in your product backlog must have its definition of done. It reflects delivering a small increment of value for your product.
Misconceptions
Everything we want to do and pops up from a workshop, a discussion, a client´s request or your manager´s whim goes to the product backlog. WRONG! Defend this or you will constantly clean the backlog and will not be able to defend and evangelize it in front of your implementation team.
All ´green´ ideas which should be reviewed and call for some product love in your product discovery must go in a completely different backlog or ´product discovery´ list.
The product backlog includes technical debt tasks and any other tasks, stories which pertain to something that has been confirmed to be built. Why not try X, Y, Z is just an idea! Don´t mess up things, please!
The marathon product backlog cleaning
The product backlog was so big that I couldn’t get to its end, nearly 600 tasks! A bunch of tasks, stories, ideas and anything you can think of!
How do you tame a beast like this? 🙂 There is more than one way to skin a cat. Just, keep calm, don´t give up and push yourself to get started!
Attack the Epics first
Group it all by epics and re-evaluate the opportunity behind an epic. If you cannot understand the value of the epic or the team member who created it is no longer a part of the company, just purge it.
If the epic doesn’t align with the strategy anymore and is far from close to your product roadmap, then just move it back to your secret pocket of ideas aka your ideas backlog. Did I say that you can organize yourself and your stakeholders by using a platform like User Voice, a simple Trello or an Excel?
Organize ideas in a centralized repository
You´ll be surprised how many ideas you can get in a B2B world as well. That’s true B2C is characterized by the voice of the customer who directly says what they are looking for. However, your B2B stakeholders would also love to contribute and share their thoughts, ideas and wishes.
Don´t panic, they will come in any shape and type of communication, be it a call, chat, a conversation or a meeting with a client. It’s your job to cope with the overflowing ideas and look for patterns in them to grow the business and build a robust product.
You can educate your stakeholders to submit ideas in a portal like internal User Voice where you can label and categorize items, create a nice and simple Excel spreadsheet, a Trello board where you can collect a repository of ideas and show to your stakeholders how you handle those. Don´t forget that they should know the internal status and what you will do next. This helps you find out who creates the idea and follow up with them for extra questions or an exploratory interview with a key customer.
Ease your life and start evangelizing a product culture, it will pay off in the long term, I guarantee 🙂
Messy backlog comes into shape
Are there any tasks which don’t belong to an epic? If the task is created by an ex colleague and the context is not clear or it´s obsolete, just archive it.
Any items which were created a long time ago (5 years!) deserve their place in the JIRA bin!
Use a handy syntax query in Atlassian JIRA to extract and access all the tasks which are old and belong to someone who you can no longer contact.
Any other older tasks which make sense, you can group them by epics or label them so that you will know and can pull them at a later stage.
If you need to remember one golden rule, let it be ´Categorize´to ´productize´. I want to go to the moon, this is probably an epic 🙂 Any single item in your product backlog must belong to an overarching theme / functionality or be labeled in a way to denote its importance. If you cannot categorize your items, their place is not in the product backlog, it’s as simple as this.
The bulk delete is your friend
Any obsolete, old and meaningless tasks are just easily captured with the bulk delete in JIRA and you can quickly clean them up.
Technical Debt buddies
If your team members were creating technical debt tasks here and there without a clear label or an epic, just group them in one epic and sit down to see which ones can be merged or purged. Make sure that you understand the context well enough to group and categorize them. The technical debt can put the house on fire, don’t risk your product, understand and address these on time. The first step is to understand and group them.
Product backlog is NOT your working playground
I confess, I also create tasks for myself and like having them in an organized place. I´ve used Trello for my product management work and also an epic for my tasks where I can organize them throughout the sprints. Of course, I´m referring to bigger items, smaller, daily business tasks don’t need to be written.
However, please, don´t use JIRA for your product discovery work and rough ideas. I personally find it useful to document my rough items in Atlassian Confluence in a specific product folder. Once I’m done and I start writing the product requirements, then I can create the functional requirements and break them down into JIRA tasks which belong to the product backlog. My personal tip is to create only JIRA stories for those bits which are relevant for the next product releases. If a specific portion of a functionality is rather ´nice to have´ or ´should have´and you don’t have even an idea about whether and when you want to ship it, mark with a nice label in Confluence and don´t fall into the temptation of creating placeholder task for it yet. Otherwise, you know that the product backlog will always keep bloating.
Label product backlog items
It’s true that we need a well ordered product backlog. I don’t argue about this, but want to highlight that ordering is not the only way to get an idea of the work. I personally use labelling in certain cases to add an extra layer of prioritization: mid, long term or as I call it ´house on fire´(these tasks must be handled first as they jeopardize the product, customers´satisfaction and recurring revenue). As a big fan of JIRA, I recommend labelling items as you see them fit (e.g. ´upcoming release´, ´key client´, ´product content´etc). This is crucial especially if the product backlog is used across teams or includes more than 1 product (I know that it doesn´t make much sense…However, such cases exist and the keyword here is ´adaptation´).
Don’t mess up things and create your own structure, the important thing is to choose what works best for you.
Don’t be afraid of experimenting, pivot if it doesn’t work until you find your optimal structure.