Your job as a Product Owner is full of stress:
You have regular meetings with stakeholders and customers who request new features, report bugs and come to you with many ideas they want to see in your product.
Your Development Team needs your opinions, decisions, and product knowledge during Sprint Planning, Refinement, and Sprint Reviews.
Additionally, you prepare product demos, analyze product metrics, prepare and update your product’s roadmap, and communicate with the help desk to satisfy your customer’s needs.
In nearly every meeting, conversation, and activity of your work, one artifact is present: Your Product Backlog. Yes, it is your Product Backlog.
If your Product Backlog is a mess, there is no one to complain about as it is your responsibility. Most Product Owners know that, and they feel very responsible for their backlog. However, most of them try to work their ass off to have a clean backlog.
I have seen Product Owners working overtime to prepare the next day’s refinement session. Even worse, I have seen Product Owners take a vacation to catch up with the Product Backlog work.
Usually, there is no need to work overtime and taking a vacation to manage a Product Backlog.
I hope you could get your work as a Product Owner done without working overtime or taking a vacation to catch up with work. For that, you have to understand the reasons you need to limit the size of your Product Backlog.
Here we go!
5 Reasons You Need to Limit the Size of Your Product Backlog
Without a limited size of your Product Backlog, you are facing the following scenarios:
- Finding Backlog Items Is Hard
- Duplicate and/or Confusing Items
- Ordering the Backlog Is Impossible
- Endless Refinement Sessions
- No Reason to Reject Requests
1. Finding Backlog Items Is Hard
During your workday, you receive many inquiries from stakeholders, developers, business analysts, etc. regarding features, bugs, stories, and whatever requirements you have in your backlog. If you want to clarify details, you log into your product backlog tool and search. Where is the “login story”? You are looking for “login”, no search results. Ok, let’s try “log in”, again no search results. What about “logging in”? There you are.
That is an easy example, and the situation described above might be even worse if you have stories related to more complex aspects than a login.
The smaller your backlog is, the more comfortable you will find individual backlog items without using the search function.
2. Duplicate and/or Confusing Items
Imagine a hectic workday where everybody needs to talk to you. A stakeholder asks for new features. You are in a hurry. You are not sure if you already added the feature to your backlog. Searching for existing items related to this feature takes too much time. Because you don’t want to forget the feature, you add it to the backlog just with a title and a few words of description. You promise yourself to add details to the backlog item when there is enough time.
Fewer items in your backlog lead to more time to find existing ones and reduce duplicates.
3. Ordering the Backlog Is Impossible
I am wondering how some Product Owners can order their backlog with more than 300 items. The truth is: They cannot. Nobody can. New items automatically get a high priority because they are fresh and recently raised by a stakeholder. Old Product Backlog items slide down automatically.
Ordering a backlog with 30-60 items is much easier than a backlog with 300+ items. Besides, your Development Team gets an idea whats the direction of the product just by looking at the Product Backlog.
4. Endless Refinement Sessions
Many teams struggle with refinement activity. Very often, this activity develops into a Product Owner’s presentation with a subsequent Q&A. That’s boring and tedious for developers and Product Owners.
Trying to find items and scrolling through an endless list of requirements reinforces those feelings, especially in remote meetings.
Your refinement sessions will be more productive with a reasonably sized backlog.
5. No Reason to Reject Requests
If you don’t limit your Product Backlog size, what’s your reason to reject a stakeholder’s request for new features? Imagine you have several stakeholders, and you add a request from one stakeholder, but not from the other. You might piss off stakeholders because you have weak reasons to reject an item.
As you don’t want to piss off stakeholders, you add an item you already know will never be developed. You want to please the stakeholder. Later on, you will forget this item as it slides down in your backlog.
The stakeholder believes that the requested feature will be developed in the future, as it is already in the Product Backlog. You will get asked a lot over time when the requested feature will be done.
That leads to a lot of discussions and valuable time you lose. The time you could use to clean up your Product Backlog. It’s a vicious circle.
A reasonable sized Product Backlog will avoid all the situations described above. It will reduce your workload, and you do not have to work overtime anymore.
Are You Convinced to Limit the Size of Your Product Backlog?
All of the things I described above are time wasters that leave you even less time to work on the backlog. It’s a vicious circle.
To break the vicious circle, set a maximum number of items in your backlog. I can already hear you that you don’t have time for that, and you don’t know how to come up with a reasonable maximum number of items in your backlog.
The first step is yours: You need to make a decision: Do you want to change something? Do you want to break the vicious circle and have more time for all the other aspects of your role? It’s easy: “Yes, I want to change the way I manage my backlog” or “No, I am happy with my stressful workdays”.
If you chose to change the way you manage your backlog, start here to identify a reasonable maximum number of items in your Product Backlog.