Claim Your
Product Coins
Do you ever feel overwhelmed in the labyrinth of backlog management? Navigating through methodologies like Scrum, Kanban, and more as a Product Manager, it's all too common to find ourselves tangled in this complex labyrinth. With an overflowing calendar, endless follow-ups, and an ever-growing personal to-do list, the struggle of managing your backlog effectively can sometimes seem impossible. Trust me, you're not alone in this - the challenges of backlog management are a shared burden among us.
As a Product Manager who has worked closely with over 20 teams using Scrum, Kanban, and other methodologies, I understand how challenging it can be to maintain oversight of a backlog. Juggling a full calendar, numerous follow-ups, and a lengthy personal to-do list can make this challenge even harder.
However, over the years, I've learned that managing a backlog doesn't have to be this tough. It can be quite an enjoyable task, and you'll quickly realize its positive outcomes, especially in terms of time-saving.
This realization led me to create this blog post. It aims to help you establish a structure that encourages both you and your team to jointly contribute to the backlog. You can anticipate several positive side effects, including less chaos and waste in your backlog, clearer priority-setting, more efficient backlog grooming and sprint planning meetings, and projects with well-defined scopes.
There's one more thing I need to share.
Achieving a clean backlog requires a substantial commitment of time and effort. I encourage you to set aside two hours each week for a month, solely dedicated to managing your backlog.
The investment will yield a significant return: More time for you and your team
Let's start by clarifying a few concepts about the product backlog:
Understanding these fundamental aspects forms the backbone of your future work and projects. A shared comprehension of what a backlog entails and who is responsible for it is crucial for a smooth workflow.
So, what exactly is a (product) backlog?
The product backlog is essentially a digital or physical list containing the software requirements for a product, feature, or service. It usually includes user stories (new functionality), technical improvements (tech stories & tasks), bug fixes, and spikes (knowledge acquisition). Serving as a single source of truth for a development team, the backlog is prioritized and sorted into milestones, sprints, etc., depending on the framework employed (e.g., Scrum or Kanban).
This question obtains diverse viewpoints. Some people believe that the Product Manager (PM) or Product Owner (PO) solely owns the backlog, while others believe it's a team responsibility, with the PM providing support with business requirements.
Endless debates over "YOU (the team)” or “I (PM)” own the backlog can be counterproductive and distracting.
My pragmatic perspective is that as a Product Manager, you're a part of - not the boss of - an Engineering Team. Therefore, you and your team collectively work on the backlog to create products and deliver value to your customers. While we may co-own the backlog, as a PM, I'm responsible for defining priorities and ultimately accountable for the results. This is the guiding principle I employ while leading my team in the right direction.
Does your team also own the backlog? Food for thought!
A thoughtful quote by David McCullough resonates well with these questions:
"Writing is thinking. To write well is to think clearly. That's why it's so hard."
Backlogs can vary greatly depending on your industry and business model, from B2C to B2B or B2B2C. Nevertheless, it's essential for you and your team to agree on clear guidelines to maintain a tidy and organized backlog.
Why does this matter?
Having clear guidelines mitigates confusion on aspects like tickets with no comprehensible headline or description. They ensure everyone in the team understands the priorities and how to execute them, minimizing the struggle with 'ad-hoc' requests or last-minute preparations for meetings.
Neither for Product Managers nor for Engineers. Tickets should not be thrown into the backlog with vague intentions such as "We need to do this sometime in the future..." or "That's important! We can't forget about that…" Mindfulness while creating tickets can significantly improve backlog quality.
...they follow a common template/pattern and have a clear title and a description of what it's about. Acceptance criteria can be added once they are known. It is essential that tickets, intended to be tackled within the next 6 weeks to 3 months, are shared with the team e.g., via Slack. Optionally, the Product Manager can be notified when a new ticket is created. Remember, trust in your teammates eliminates the need for additional bureaucratic layers.
A shared understanding of a "ready" ticket is pivotal for all team members. It enables agreement on certain formats and information a ticket must contain, thereby minimizing confusion and facilitating a well-defined scope of work. If you don't have a definition of ready or are not using your existing one, you can learn more about it here 👉 definition of ready 👈.
Ensure the next 4-6 weeks are planned, and most tickets match the definition of ready. Your backlog should not extend beyond 3 months. Anything further should ideally be on a roadmap or Confluence pages & (technical) concepts.
P.S.: If people outside your team create tickets in your backlog, don't hesitate to share the guidelines with them. There's nothing wrong with setting expectations and refusing to accept low-quality tickets. #stakeholdermanagement 👈 (hidden link)
Recommended Action Items:
Getting everyone on the same page with the change can be a bit of a challenge. Since the whole team shares ownership of the backlog, as a PM/PO, it isn't your sole responsibility to enforce all changes. Here are some useful steps you can follow to facilitate this process that helped me in the past.
Start by setting up a "Backlog Management Review" meeting that lasts about an hour. Ensure you share an agenda in advance so everyone knows what to expect and can prepare.
Clearly communicate the goal of the meeting: to evaluate the current backlog management process and suggest possible improvements.
If your team is generally receptive to change, you might want to share some materials like a ticket template in advance. If not, hold off on sharing until you can present and explain it in the meeting.
Start the session by addressing why you are all gathered and the issues at hand.
Recall the question: What are the major hurdles you face with backlog management? Is your backlog overwhelmed? Are tickets often unclear? Is your backlog lacking enough tickets? Are you aiming to improve your structure and planning for releases? Or, are you looking to kick off a new backlog or project?
Discuss your concerns and objectives with the team, then lend an ear to their feedback and proposed solutions.
After discussing potential solutions, share your ideas and invite others to do the same.
Before ending the meeting, ensure you have either:
a) agreed on actions to be taken [A, B, and/or C]
b) or set a clear follow-up date for decision-making.
For your team, the benefits include:
But, what if there's resistance or disagreement within the team? Let's explore that...
Resistance often stems from fear. So, strive to understand what's causing the apprehension rather than getting frustrated at the disagreement.
One effective way to unearth underlying fears or issues is to ask probing questions like:
You could also present the problem logically. For instance, if your backlog has 300 tickets and you close only 5 every two weeks, it will take more than two years to clear the backlog.
Point out that around 80% of the tickets will probably never be worked on, regardless of how "important" they may seem. If they aren't getting addressed, they simply aren't important enough.
If these strategies don't work, there's another option: the "agree to disagree" approach. It's not always popular, but it may be the best course of action.
Offer a trial period of 1-2 months for the new approach, followed by a review session or retrospective.
Recommended Action Items:
If you're interested in learning more, you can tune in to this podcast episode specifically dedicated to product development processes.
This is the most hands-on section of this guide, focusing on backlog preparation and clean-up. You may already have your own norms for ticket writing, and that's a great starting point.
Superior Product Managers are also exceptional problem solvers. It's critical, to begin with a precise problem statement and its underlying reasons. This idea should find expression in your backlog as a "parent ticket," to which you'll eventually link all user stories, tasks, and more. I've provided a methodology for ticket writing and using different ticket types in previous articles.
Remember, there's no need to get hung up on this. If your preference leans toward fewer or more ticket types, adjust accordingly. The priority is to gather pertinent information that guides your team in developing the right solutions in the right manner.
The same rule applies to user stories and any other tickets. It's advisable to adhere to the INVEST or SMART framework. My experience has proven these two models to be the most effective.
An important final step is to properly link tickets! This is essential for maintaining the visibility of your team's activities. I suggest that both you and your team regularly remind yourselves about this.
If you're drowning in tickets (where your velocity/throughput < the number of new tickets), it's time for some housekeeping!
Firstly, decide which tickets to close. I frequently relied on the practice of closing all tickets older than three months. You may adjust this timeline based on your requirements, but I wouldn't recommend exceeding three months.
If you categorize bugs, customer requests, or other tickets differently, you may opt to exclude them from this process (this tends to be more applicable for B2B than B2C). Nevertheless, I'd advocate for being as thorough as possible when closing tickets.
If you inadvertently close a critical ticket, rest assured, it will resurface, and you can address it then.
As emphasized, it's important to discuss your plan with your team. Be prepared for potential disagreement with your approach.
What if my backlog is too “empty” afterward? 🤔
That's actually fantastic! Don't fear an empty backlog. You've merely cleared out less important tickets, paving the way for a fresh start. And Seriously: Do you believe it will stay like that?
Closing tickets is not a negative action. They can always be reopened, provided you don't delete them. Remember, closing a ticket doesn’t equate to deleting it.
To gain your team's buy-in, you could create a query of all closed tickets and share it with them for regular review.
For the super-organized among you, consider setting up a monthly Slack reminder that shares the query link in your team channel.
It's crucial to keep up this routine of regular ticket cleanup.
Recommended Action Items:
My goal is to help you establish a routine and structure for maximum efficiency and effectiveness in your future work. Following, some more practical actions for you to move forward.
It might sound like a trivial task, but do you have a recurring event on your calendar? And how often do you skip it or allow another meeting to overlap?
I propose creating an event titled, for instance, "Backlog Preparation Session" rather than "Blocker," to dissuade others from scheduling over it.
You may not be aware of all the details, acceptance criteria, dependencies, etc. Therefore, when you're crafting tickets, ask your team for their input. Post your queries and tickets in team channels and encourage team contributions.
Remember, it's important to define clear ETAs to avoid a backlog of unprepared tickets.
Additionally, backlog grooming is an excellent opportunity to refine tickets and prepare them for development. Everything you need to know about groomings is summarized here:
👉 5 Steps to Make Product Backlog Groomings More Engaging 👈
Here's another tip: If you have a well-defined epic, you can ask your team to break it down into user stories. Imagine you're building a feature that's heavy on UI. Your team has a better understanding of how to segment the stories and slice them. This only works, however, when the epic includes all key information, including designs or wireframes.
Regardless of whether you use Scrum or Kanban, it's vital to have a plan prepared at least four weeks in advance. Make sure you have a neat placeholder sprint, release backlog, etc., prioritized from top to bottom.
If you're new to this:
The most critical tickets always sit at the top of the backlog. Teams should always pull from the top of the backlog.
There are three types of teams:
The third category comprises the most successful teams. If you work with a Scrum Master or Agile Coach, I recommend collaborating with them to guide the creation or use of the DoR.
For those doing Scrum, it's suggested to estimate tickets and plan team capacity. I've written an in-depth article, complete with a free planning tool that you can use.
You've taken a big step toward mastering backlog management. If you're hungry for more practical tips, sign up for my newsletter. Here, we delve deeper into the nitty-gritty of product management, ensuring you're always on top of things.
