“Chaos is merely order waiting to be deciphered” (a line from José Saramago’s The Double) suggests that we are able to make sense of things that seem chaotic. We just have to learn how to decipher it. In my career I have seen Product Owners struggle with the backlog. I have also seen backlogs with 15 years of requests, bugs and tasks in Jira. Within a month of joining I am able to decipher it and bring order to that chaos. I will share my process of backlog management.
Understanding your backlog
Knowledge is power, and a large backlog can help you unlock that power. My goal is to break down the backlog into manageable blocks that is easy to learn from.
First I split them into streams of work that can work in parallel. For example:
- Bugs
- Tech Debt
- Product
I then split streams into buckets. Buckets are a way to group items into a category. For products, splitting into big features/use case works well. If a bucket is too big, I split it further. If a bucket is too small, I group them with other buckets.
Now I can analyse each bucket. For example, I split the product stream into functional buckets. For each bucket I add the following:
- Analytics. How frequent it’s used and how many customers use it.
- How valuable is the feature to the business? If it’s a core concept or a differentiation.
- Quick write up on the analysis of the items in the bucket to detect trends. Reviewing 30–50 items is easier than the full backlog.
Product Development Flow
Now that I have a better understanding of what is in the backlog, I will focus on how ideas flow to the team, I have 3 main parts:
- Data (old backlog) that will support any work the development team will work on. I use a request issue type in Jira so it is different workflow to what a team works on.
- Roadmap that will give teams a strategy and path to success.
- The Team’s board (new backlog) which will give them focus on what they are working on now.
I do the following:
- Create epics as candidates of the roadmap from the analysis of the backlog. I link related requests to the epic.
- Prioritise the candidates using scoring techniques. Then move the top candidates to the Now, Next and Future columns. The epics will flow through the roadmap as things are done.
- All Epics in “Next” can be exposed to the team to discover the correct solution. Tasks can be created for activities for the team.
- All Epics in “Now” can be exposed to the team to deliver the chosen solution. User stories are created to break down the delivery of an epic.
- When we finish the epic I review all user stories and requests to either close them or move them back as a set of requests for future consideration.
I no longer need to manage 1000 issues. I can then manage at most 15 epics where 1 is being implemented and 2 are being discovered.
Systems and Habits
Now that I have years worth of rich data and a workflow that will keep the backlog current, I need to build a system to ensure new information is captured, backlog remains clean and is built for change.
Continuous Feedback
Ideas come in different forms and from different channels. The first system I create is a simple triage process that usually reviews a small handful of new items. Requests will either result in:
- A user story for an epic that we are working on Now.
- Linking to any epic in the roadmap as a reference to the problems to solve.
- If the idea is big and quite valuable, convert it to an epic to be prioritized in a roadmap review.
- If there is no epic related to it, I put the item in a bucket for future analysis.
Rituals
Change is inevitable, so we should be prepared for it. These are the following rituals I follow to ensure minimum time from a Product Owner to manage changes in the backlog:
- Daily Triage — I spend up to 15 minutes a day to triage new requests.
- Planning sessions — We meet up every one or two weeks to review the upcoming user stories ensuring they are correct and work towards our goals in the epic.
- Product Review —Every two weeks we gather feedback on recent changes that will feedback new user stories on epics we are working on.
- Roadmap Review — We meet monthly to review the roadmap priorities. This will move epics across the board.
- Analysis of the backlog — Every quarter, I do spend time to see if there are new insights. Since my triage process is ensuring the buckets are up to date. New analysis is faster to do. New candidates can be created.
Scale the Product Owner
Finally, I want to scale myself to focus my efforts on product management. What worked well:
- Use templates for Stories to ensure they’re created in the right format by any team member.
- Automate scores with some simple input during the triage process.
- Use dashboards to visualize the distribution of my backlog.
- Bulk Actions — I would find all requests older than 1 year with and add a comment that it is stale. For all requests older than 2 years old and only had one customer requesting it, I closed with a comment to re-open if it’s still valid.
- Teach the team to be a Product Owner. How to split stories, how to prioritize, how the system works.
Bringing structure around the chaos
I now spend less that 10% of my time in the backlog allowing me to focus on generating insights from qualitative and quantitative data, discovering opportunities for the product, working with teams to design and deliver the best solution and focusing on the product success not on the Product Owner role.
