Is your product backlog ruining your life? 5 steps to getting your backlog back on track

How to manage your product backlog efficiently and save time. From removing unnecessary tasks to planning and estimating. How to keep your backlog from mutating into an amorphous blob.

I haven’t heard as much grumbling about the Agile manifesto, scrum guide and other ways of working lately, so I thought, why not stir the pot?

I’m not prescribing a specific way of working, and when it comes to Product Ops, what works best will depend on the many factors your company and teams are dealing with.

At my current company, we don’t have sprints, and we don’t use project planning software. Regardless, we still have backlogs, and there are some general principles you can follow here if you, too, have a backlog.

It’s not sexy, but now and then, we product managers have to prioritize backlogs and write user stories with acceptance criteria. Whether you believe this should be part of a product manager’s job or not doesn’t change the fact that this responsibility often falls to product managers within many companies, especially smaller startups, where there often aren’t separate product owner roles.

Step 1: Avoid having your backlog become a wish list

As this is just part of our job, keeping the work from spiralling is important. Product backlogs can quickly become a never-ending to-do list of nice to haves, bugs, customer requests and those shoes you bought, totally intend to wear, but they never really fit right, so they just sit there taking up space in your closet… and in your mind.

That’s one reason why backlogs become such a dumping ground: everyone needs somewhere to put their ideas, and everyone wants to feel heard. If they don’t put them there directly, they’re telling you, and you’re adding them.

Enter a service like Product Board (not sponsored), Intercom, or similar that helps with collecting ideas because this should happen somewhere other than your backlog. Your internal and external feedback can get tagged and eventually turn into a list of ideas. The benefit is you get the raw feedback, not just the “solution,” and if done right, you may even be able to follow up with individual customers for clarification.

Ok, we’ve cleaned up some of the backlog, but how do you prioritize what’s left?

Step 2: What’s in a backlog?

You might already be a pro, but for the rest of us, let’s cover the basics so we’re all on the same page:

• Epics (Features) - A collection of user stories that often stretch across several sprints.

• Stories - A chunk of deliverable work, ideally a functional slice, but not always.

• Tasks - The things engineers do to get the work done.

And within Stories, we typically find:

• User Story - Often phrased like “As a [user], I want to, so that,” this should give your team their why.

• Acceptance Criteria - The functional capabilities of the user story, i.e., the user is redirected to home page after login

• Definition of Done - Ideally, this should be part of your story template and include pre-agreed criteria for what constitutes done where you work, i.e., unit tests written, metrics tracking integrated, deployed to staging.

One place you may be able to save some time, is the Epic. I find it helpful to structure this like a PRD, and in some cases, it serves as your PRD. It’s important to include details like:

• Business Value

• Goals / Outcomes

• Problem Statement

• Scope

• Functional & Non-Functional Requirements

• Risks and Assumptions

Because it’s an Epic in JIRA or similar software, you also conveniently get:

• Timelines

• Dependencies

• Breakdown of Stories

• and Estimates

Suppose you need to communicate these details to other stakeholders. In that case, you can conveniently link them to a Google Doc leveraging capabilities like JIRA smart chips, which stay synced with JIRA to show the status of each story and a tool like Zapier to sync the contents of the epic for your PRD. If using Linear, you can get similar functionality within Notion.

Having your project management tool serve as the source of truth helps limit the number of places you’re updating this information.

Step 3: Prioritize your backlog

Just like it’s tempting to add all your ideas to the backlog, it can also feel like you need highly detailed epics and stories looking months ahead. I prefer to plan the details a sprint or two ahead and have less granularity or detail the further I look. Beyond that, you might only have epics and no stories. It becomes more of a now, next, later prioritization and should only have some high-level effort or confidence estimates (small, medium, large).

This means you might know we’re working on improving customer onboarding sometime next quarter, and although you have some ideas of where that user flow needs improving, you don’t yet have detailed designs or engineering specs. Planning this work months or quarters in advance is not helpful because a.) people will forget the plan by the time you do the work, and b.) everyone having that much context about things that are months away distracts from the work at hand.

Step 4: Planning meetings

I’ve worked at companies with half-day sprint planning meetings, and a lot of that came down to product management not having enough details about the work. Rather than getting some details, reworking the problem, and then coming back for planning, we’d do the rework right then and there. It was highly inefficient.

This is why I typically suggest having a pre-planning meeting first. This would be a mid-sprint meeting to review what you’ve prioritized for the next sprint. This gives you a chance to get engineering feedback, reevaluate priorities based on said feedback, and know where the gaps are. Generally, there’s no estimating being done here, and it can be an hour-long meeting. Anything that needs to be discussed in more detail can be done in a separate meeting, or a-sync, with just the relevant people.

This means that by the time your actual sprint planning meeting comes around, you’re much better prepared, and after reviewing a few of the changes, you can jump into estimating. This meeting should also be no more than an hour.

Step 5: Estimating

Unless you have a standardized process for doing something, it’s unlikely you can truly know how long it will take to complete a specific user story or epic. Estimates should happen only once the work is well-defined and shortly before a sprint. This is because things can change month to month, and what was easy six months ago could become much more complicated because of changes in the product, or it could be far easier now.

Avoiding time estimates is a good rule of thumb here, and focusing on complexity/effort gives you much more flexibility. Many studies have proven that blind group estimates produce a realistic average (if given enough people), and there are a couple of planning poker tools that can help with that; see included links:

• https://deniz.co/slack-poker-planner/

• https://pointingpoker.com/

A Fibonacci sequence is generally accepted, but so is T-shirt sizing. Regardless, aligning the team on what this means is most useful. I prefer to define it like this and have found doing so removes a lot of uncertainty:

• 1 (or small) - I could write the code with no assistance and have it on production within a day or two.

• 2 (medium) - Stack Overflow or Cursor AI might help, but I generally know how we can do this.

• 3 (large) - This requires some planning, maybe some architecting, and there are parts we’re unsure of.

• 5 (extra large) - There are significant unknowns. Breaking the task down into smaller parts can isolate those unknowns and lead to better estimation.

• 8 (extra extra large) - “I don’t know how we’d do this.” Something this large needs a research spike and likely needs to be broken down into smaller pieces.

Hopefully these 5 steps are a helpful start to getting your product backlog back on track. You may already be doing some of these things well within your organization, but hopefully there were a few takeaways you can leverage to improve things even further. With the right approach, backlogs can become a useful way to prioritize and plan what your teams are working on next.