I spotted 9 problems in a healthy looking team backlog
What were the issues and How did I spot them so quickly?
“It looked polished at first sight, but after five minutes my PO-alarm went off.”
Just last week, I reviewed a team’s backlog that initially appeared clean and healthy. It was well-organized, detailed, and looked like a Product Owner’s dream setup. But within 5 minutes, I spotted 9 issues.
These were the same problems I see teams struggle with over and over, without even realizing they have a problem.
After so many years of working with agile teams, I've developed a 6th sense for spotting these backlog problems.
In today’s post,
I’ll walk you through these 9 issues.
I will outline my complete thought process, including sequential steps, for inspecting new Product Backlogs.
With that, let’s get started.
If you’re new to Winning Strategy, here’s what you missed in past few weeks
How we moved from Scrum to Kanban without disrupting team's ongoing work
How did we design our First Definition of Outcome Done Workshop? (Part-2)
How to Fix: Testing is Falling Behind Causing Production Bugs.
Issue #1: Huge Backlog
I noticed that the backlog was bloated.
I could scroll on and on, far beyond the work the team can realistically refine or deliver within the next couple of quarters.
I checked the following numbers:
Backlog size: Size ÷ Avg stories completed per sprint > 20 means ≥ 6-month inventory
Item Age: Median “Last Updated” date > 60 days
Zombie Index: % of items untouched in 90 days. Healthy ≤ 15%; Bloated ≥ 40%
When the size of the backlog far exceeds the team’s ability to refine and deliver items within a reasonable time horizon, then there is a problem. Anything older than 1–2 quarters leads to delayed decision making.
This particular backlog contained hundreds of items, many of which were untouched for months.
Best practices to avoid this from happening:
I usually ask the teams to cap the delivery backlog at 1–1.5 times the team’s average quarterly throughput; new ideas are placed in an “Idea Bank” (separate Kanban board) until space becomes available
Block 30 min every month (or 2 months) to archive aged items, merge duplicates
Create a Jira report that shows the % of items untouched in 90 days; set an alert if it exceeds 15%
Got an urgent question?
Get a quick answer by joining the subscriber chat below.
Issue #2: Placeholder Stories
I noticed many backlog items with titles or descriptions like “TBD,” “Fix later,” or “<feature name> details coming.”
These placeholders were occupying space in the list but providing no real information for the team to refine, estimate, or deliver.
This usually happens when (1) anything mentioned in a meeting is instantly converted into a Jira ticket, regardless of content, (2) PO logs a reminder with “fill out later,” then never circles back, or (3) Team records every request immediately to avoid “forgetting,” even when context is missing.
I checked the following numbers:
COUNT(stories WHERE acceptanceCriteria = NULL) ÷ totalStories > 20%
% of backlog items with no estimate > 30%
Median “last updated” > 45 days for unestimated stories
Best practices to avoid this from happening:
Create a separate Kanban board (idea bank) for raw thoughts
Only the ideas that fulfil the following list graduate to the backlog:
clear user/problem statement
acceptance criteria (Given/When/Then or equivalent)
rough estimate (points or T-shirt)
PO and tech lead spend 30 min clearing drafts before the full-team refinement meeting
Issue #3: Precision estimation for future items
I look for backlog items that won’t start for 6 months or more, which already have story-point totals, hourly breakdowns, and promised dates.
This “precision forecasting at maximum uncertainty” bakes brittle numbers into roadmaps and budgets long before the work is understood.
This mainly happens when:
Finance requires a cost for every feature for the next fiscal year
Sales commits to fixed-price, fixed-scope bids before backlog
Teams write an inaccurate number to avoid leaving it blank
Stakeholders view the early estimate as a firm commitment. Later, realistic re-estimates meet resistance because they “exceed (usually) the original number.”
Best practices to avoid this:
No story receives points until it’s expected to start within two sprints
Epics > 90 days out show only bucket sizes, not points
Detail only the items in the next 1–2 sprints. Outline the next quarter in medium detail. Keep anything beyond that at the epic level
Check out the post below:
Issue #4: User Stories that were Epics
I noticed individual backlog items that looked like normal user stories, but were so large that they couldn’t possibly be completed within a single sprint.
I checked the following:
Size vs. Sprint capacity: Story Points > 25% of average sprint capacity
Sub task count: Story contains ≥ 10 subtasks
The title starts with giant nouns: “Platform Migration”
Multiple personas in a single user story
Huge acceptance criteria
In such user stories, stakeholders cannot see or test the value until weeks later. There are multiple dependencies, but the user story hides the need. Devs jump between sub-tasks while the story stays “open,”
Best practices to avoid this:
Highlight any story whose estimate equals previous epic sizes
No story > 13 pts or lacking a goal enters Sprint Planning
PO partners with a senior dev during drafting to check giant scopes early
Team commits to goals, not outputs. If a story alone is the sprint goal, it’s probably an epic
Split user stories using T-Split
Problem #5: Missing Personas
Backlog items started with “As a user I want …” or skipped the “As a …” clause entirely.
When nobody knows who the story is for, decisions about UI, performance, language, and even priority become guesswork.
To avoid this from happening:
We requested that the admin create a mandatory “Persona” field on the issue screen in Jira
Designer pairs with PO and the first question they ask is: “Who exactly is this for?
Scrum Master was asked to check that each story starts with “As a <SPECIFIC PERSONA> …
Check out the post below if you need help in creating Personas:
Problem #6: Missing “so that…”
There were some backlog items (stories, bugs, even epics) that were written without any explicit connection to a measurable product outcome.
Examples:
“Dark mode toggle needed”
“Refactor payment service”
“Add XML export option”
etc. etc.
They were floating in the system as “outputs,” and it was impossible to know why the team was doing them or whether they should be done at all.
To avoid this from happening:
Every quarter, POs must map their epics to the new objectives
During backlog refinement, ask: “Which outcome does this serve?” If none, the discussion is stopped until PO finds the “outcome”
Items that remain outcome-less for 30 days are moved to the idea Kanban board
Output without outcome is just busywork. Tie every line of code to a product goal, and question why you’re writing it.
Problem #7: Forgotten Dependencies
Many backlog items carried dependency links (“is blocked by”, “depends on”, “waiting for team X”). Those tickets remained unchanged for months.
When I inquired, we found the following root causes:
Owning team changed priorities but never updated dependents
PO added dependency links during road mapping, but didn’t discuss with the team
A tech spike blocked a feature. The spike was closed, but the link was never removed
To avoid this from happening:
Hold a weekly Scrum of Scrum and make sure to review blockers
Publish which team owns which dependency + usual lead-time
Write the target date of resolution
Update the blocker every 7 days
Try to split stories vertically so there are no dependencies to begin with
To learn how to manage dependencies, check out the post below:
Dependency Management For Scrum Teams + Template
A dependency ignored for over two weeks is no longer a plan.
It is a risk.
Problem #8: Untestable Acceptance Criteria
I noticed many stories in the “Done” column, with acceptance criteria that were like:
“Should work on all browsers.”
“Must be user-friendly.”
“Follow design guidelines.”
These polite but untestable phrases provide QA, developers, and stakeholders with no objectives to determine whether the work is actually complete or releasable.
Root causes included:
Copy-paste templates: Field auto-populates with “Acceptance criteria: 1) … 2) …” and nobody fills the bullets.
Fear of commitment. The team was worried that strict tests would expose unknowns
Time pressure. PO wrote criteria in the meeting chat: “Basic functionality works.”
To avoid this from happening:
Make sure the Acceptance Criteria describe observable behaviour
Example: “WHEN the user taps ‘Save’, THEN a green toast saying ‘Profile updated’ fades in for 3 seconds.”
Make sure the AC includes at least one edge case
Example: “GIVEN the password field is empty, WHEN ‘Submit’ is pressed, THEN the button stays disabled and an error ‘Required’ appears.”Put numbers on performance or limits
Example: “The GET must return 95% of requests in ≤ 200 ms.”Uses data examples
Example: “With a cart subtotal of $120 and a tax rate of 19%, the final amount shown is $142.80.”And… make sure the AC is written before coding starts
Problem #9: Unresolved Spikes
“The spike that never ended.”
I noticed several “learning” tickets that were still sitting in the backlog even though their time-boxes expired weeks ago. They haven’t produced a documented result, decision, or follow-up action.
Best practices to avoid this problem:
Attach a time box and a success metric to every spike
Size Spikes to max 2 Story Points or 3 dev-days
Owner of the spike actively posts interim results
Results & decisions (after the timebox is done) are documented
My backlog skimming process
I find reviewing product backlogs incredibly boring, so I created the following process.
I use this order as a guide to walk me through each time I inspect a new backlog.
Further Reading
Show your support
Every post on Winning Strategy takes ~ 3 days of research and 1 full day of writing. You can show your support with small gestures.
Liked this post? Make sure to 💙 click the like button.
Feedback or addition? Make sure to 💬 comment.
Know someone who would find this helpful? Make sure to recommend it.
I strongly recommend that you download and use the Substack app. This will allow you to access our community chat, where you can get your questions answered and your doubts cleared promptly.
Connect With Me
Winning Strategy provides insights from my experiences at Twitter, Amazon, and my current role as an Executive Product Coach at one of North America's largest banks.
Hi Vibhor, I cannot thank you enough for this post.....It is so relevant to my situation right now. Since the PO and other stakeholders are not inclined to delete older items, I have moved them to a newly created board, essentially a graveyard, knowing we will never use them. But at least it's not clogging my active team boards, so I guess that's a win :)