Product Backlog Management: Tips from a Seasoned Product Owner

Added to Business

A Product Owner's best friend is Agile Principle #10:

Simplicity -- the art of maximizing the amount of work not done -- is essential.

If you are a product owner or a member of a team you have probably gotten this feeling each week when you are called into the Refinement or grooming session:

Oh no. Not Again.

If you've never had that feeling, then maybe this article is not for you.

Here are some general expert tips for product owners and teams that are based on my life as a product owner and being a coach for teams internationally.

The backlog is not an infinite list of things to do with no relation between items.

Backlog listThink of the last time you had to deal with a list that had a million items. Humans in general love lists but hate long ones. We often can't remember beyond the first few items.

It is also true that humans don't do well with one-dimensional monochromatic information.

There is a common saying in Scrum teams: “Put it in the backlog”. As a customer or product owner, when I hear this I think, “There it goes, this stuff will never get done”.

Try using a Problem Board that has notes for each category of work, but not all of the work in one list.

  1. Define a business problem you are trying to solve or a goal that you are trying to reach.
  2. Define a metric that describes how you can measure the fact that you are actually solving the problem.
  3. Define the features that can help you solve the problem.

You may have 20 to 30 goals or problems that you are solving in a quarter, irrespective of the scale of the product.

Getting items to a manageable lists

There is a myth in the Agile community that adding to the backlog is the easiest thing to do.

If there are 100 things in your backlog, and if you team does 5 items in a 2-week sprint, they need 20 sprints to finish the list.

If I am a stakeholder and I see my issue being added as the 101st item, I know I will not see it addressed for at least another six months to a year.

Backlog management

The concept presented is not new and has been validated by folks like Jeff Patton of Agile Product Design. Think of a product backlog as a uber list of three lists.

Opportunities: Any raw idea goes here. This is just acknowledging you heard someone. But you need to spend some time making sure what you added makes sense. Many times people are describing a problem they are facing or maybe saying something they think they need. Remember, you don't know if this is a useful idea until you actually build it.

But building something is a huge cost. Remember the 80-20 rule: for every 100 items hitting the opportunities list, you push 20 to the filtered backlog. The 80 others hit the “Trashcan Backlog”.

A good product owner should validate each feature to see if the feature being built meets the goal. Let's say you thought this feature is good, all the initial research you did shows that this is good, so you built it. You are surprised to see that even after a month or two of being in production, no customers are using it. Invoke Agile Principle #10: Do not shy away from requesting the team to take away the feature, the code, the test, etc.

Good product managers don't always get things right. They experiment with ideas and try to validate them, but take them out if they don't make sense based on measurable metrics.

Estimating Stories is a non-value-add activity.

Many teams struggle to get estimation right. Remember estimation is never correct, hence the word "estimate". Agile teams use estimates to do a few things: to tell the PO they can do the stories in a sprint, to show confidence among team members that they can actually do it, and to gain a better understanding of the feature they are trying to build.

Non-value-add activity is anything that the customer cannot see. In most cases, the end customer cannot see your estimates or doesn't care about them. Instead make sure every item you put in the team backlog is ready and possible to do in a sprint. It does not matter if it takes one day or 10 days. What matters is whether it goes into production at the end of the 10th day and creates output. Solving a customer's problem is outcome. What we want is outcome not output.

Don't fall into the business value trap

Product owners often struggle with how they are going to assign business value to a story. Many coaches and Agile gurus subscribe to this rule. Guess what -- there are hardly any product owners who can do this well in a simple manner. There is a lot of theory around this, but really all we should care about is at the problem/goal board level -- we should be able to identify a metric that tells us we are reaching a goal.

So don't beat yourself up if you cannot find a way to assign business value to a user story.

Don't fall into into the "As a User, I want to Do Something" trap

“As a user, I want to do something so that <value>" was only meant to be a template. Little did we know that the world would turn around and spit out thousands of items on a backlog. It is really tough to read this machine language. Humans read backlogs not computers.

Instead, consider as a product owner doing a short 2-minute video of you describing the story to your team in a flip chart. One of my favorite product owners living in Germany does this all the time because her team members are in four countries.

Remember to value People over Process

Do what makes sense to you and the team. There is no right or wrong here. The only thing that matters is whether you can offer something of value to a customer that solves a problem they have.

Lastly, have fun with the team as you build the product. The backlog is just a medium to capture your thoughts. Without your voice behind it, it makes no sense. Talk to your team more often and see the difference.


About the Author

Vibhu Srinivasan is a self-described "Agile Practitioner and Entrepreneur” who has been spreading Agile values and continuously striving to improve the happiness quotient since 1996.He is a teacher, blogger, speaker, leader, and a well-known face in the Agile industry particularly in India/US, with experience working with organizations across the world who champion the concept that “Happy People Create Happy Customers.”Vibhu has a wealth of experience working with techniques like Lean, Extreme Programming, Scrum, and others that fall under the Agile umbrella.Vibhu is the Managing Director for SolutionsIQ India, a one-of-a-kind employee-driven organization providing consulting and development services for customers across India and Southeast Asia. SIQ India is home to the best Agile Practitioners in tha region.He has also been a Certified Scrum Trainer (CST) since 2010. He is delighted to be the first CST of Indian origin. Since beginning as a trainer, Vibhu has trained nearly 5000 people in Scrum, Agile thinking, leadership, and professional coding (AKA “clean code”).Prior to coming to SolutionsIQ, Vibhu was part of another people-driven organization called Spiderlogic where they ascribed to the mindset of “Architects who Code, Coders who Architect”.After studying Electrical Engineering and earning his Master’s degree in 2006 from University of Wisconsin School of Business in Madison, Vibhu has busied himself starting up and leading a variety of businesses, always in the position of leader, executive, or influencer.He is one of the early founders of the Geek Book Club in the Midwest, which started in 2000. He advises start-ups in Seattle and India and is always ready to build the next useful idea. Vibhu lives in Seattle (USA)—and in Bangalore (India)—with his beautiful wife and business/life partner Arati.He is reachable best by email and appreciates when people tell him why they are adding him as a friend.


This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.


  • wonderbrett

    Good article! Thanks for this.

  • Hanna

    Nice article. I often struggle with backlogs so I’ve read it with great interest. I think boards are perfect for dealing with backlogs as long as, like you write above, they’re organized in manageable way and with possible to finish amount of tasks. My board tool has some features that help me in prioritizng things and triggers to wonder if all the tasks are really necessary to be put onto board (http://kanbantool.com/blog/how-to-deal-with-an-ever-growing-backlog ). To be true, one of the best things that helps me in following the (still manageable ;)) plan is… color. Colors on my board. I avoid choosing red color – that means an alarm to me – for too many tasks. It’s difficult sometimes as I’d like to do all the things immediately but limiting the plan’s worth thinking about. Being in rush all the time isn’t helpful at all.

  • Dave Armstrong

    Great article, I am looking into backlog management right now and am reading a few different articles to try and help me formulate a plan. I am curious, you mention a Product Owner in Germany that does Flip Chart videos for describing a feature, can you provide any more information on that?