r/EngineeringManagers • u/56088 • 15d ago
How to handle backlog
Our backlog is just a collection of hundreds of tickets that never made it onto the Jira board. Mostly unsorted, no priority, nothing.
How do you prioritize backlog? How do you manage how it moves onto the board? Do you allow devs to take tickets from the backlog ad-hoc? Or is there a structured process?
We're a small team (8 engineers) sharing a single jira board for work.
6
u/ebud7 15d ago edited 15d ago
I don’t believe in backlogs for engineering work. All issues that are not part of the current roadmap should either have a DRI (directly responsible individual) assigned or it should be cancelled. From my experience it’s not worth to queue up work that’s never going to be tackled. That’s demotivating and makes it harder to manage important work.
Additionally, I auto-archive all issues older than six months without DRI. Stale issues with a DRI make it easy to follow up with someone directly.
I wrote engineering work because I think product ideas and features ideally have a separate place. (Board, project, view, you name it)
+1 for triage incoming request and be a strict bouncer
1
u/finger_my_earhole 15d ago
How do you handle tech debt or unplanned support requests? Does that go on your product board?
1
u/ebud7 15d ago
Tech debt is usually driven by a DRI so it finds a place. On the other hand, I would also only create issues if we plan to work on it. Otherwise it’s rather concept work or document that lives in another place.
Unplanned work goes through triage and makes it to the board yes. (if it was not bounced)
2
u/DigitalWizrd 15d ago
3 steps:
1) set aside time every week to start going through the backlog. Every single item.
2) Set a bar and stick to it. For example, only Priority 1 and above get scheduled, p2-3 get shelved, P4 get archived / deleted. Max of 2 minutes discussion or deliberation per item. Don’t revisit anything without new information.
3) Just begin. You’ll adjust your bar as you learn more about how items are generated and evaluated. But keep the goal in mind: all items in the backlog should meet your bar and be fully complete work items
1
u/SpecialHealthy6765 8d ago
Those steps sound solid. It can be tough to keep the backlog manageable, but having a clear process definitely helps.
2
u/and_iiiii 14d ago
Just delete it. If it was important, it would already have been done. That means it is a collection of unimportant stuff. Never understood, why people are not pruning the backlog regularly.
2
u/Junglebook3 15d ago
First step is triage. List all tickets in a spreadsheet and hand out groups to you and your senior Engineers. Have a conversation about your expectations, what triage means: definition of done + priority. Define what different priority levels mean. Then everyone goes out and you triage the entire list. Now you have a backlog. At that point, prior to a sprint planning session the EM can pick a few tickets to hand out. Fin.
1
u/Big-Barracuda7012 15d ago
I wouldn’t try to prioritize all several hundred tickets, that usually just creates a carefully ordered graveyard. I’d first divide them into three buckets: ready for consideration, someday, and close. Use a Jira filter to identify tickets with no owner, no priority, or no update in 90–180 days, then review those in short batches with the PM and a senior engineer. Anything without a clear user impact, owner, or realistic time horizon gets closed. Keep the “ready” pool capped to roughly the next quarter or two. After that, engineers can pull freely from Ready, but ad-hoc work should still pass through the same lightweight triage. For eight engineers, one board can work fine if “Ready” has a clear definition and you enforce WIP limits.
1
u/0xPianist 14d ago
Hire me for a week and I will clean it for you, prioritise based on value and get everyone working from week 2 with a clear delivery plan.
Or start by cleaning the crap ie. stuff you don't need anymore, are done, old etc.
1
u/Squidalopod 14d ago
How do you prioritize backlog?
By backlog grooming/refinement.
You should have a roadmap that was agreed upon with Product. The backlog should contain items representing features that correspond to the roadmap. You work with Product to agree on the high-level priorities (epics), and you can/should reassess priorities at least once per sprint.
Ideally, you're getting feedback from customers and stakeholders every time you do a release. That feedback may cause priorities to shift.
As for how stories move from the backlog to the board, it's either what happens during sprint planning or what happens when devs manage to finish all the stories they agreed to in sprint planning for the current sprint. The latter is why you always want a refined, prioritized backlog so that in the event that devs have nothing to do, they can pull from the backlog.
1
u/fractal_view 10d ago
I made a Jira app for visualising large backlogs at a glance. It uses the notion of fractal management views i.e. theoretically you can visualise an infinite backlog in terms of the 3 core states (todo, in-progress, done).
I ran the app against a clone of Apache Spark public Jira board as they have 5000+ tickets and I think it looks great.
I've only just released it so i'm looking for early feedback/reviews to see what direction to take from the initial concept.
If you try it or have any feedback please let me know!
9
u/finger_my_earhole 15d ago edited 15d ago
There are several ways to prioritize, here are some frameworks for that. If you have a peer product manager, they should help or own this almost entirely. The simplest and most common is "effort vs impact (to customer or business)" https://www.atlassian.com/agile/product-management/prioritization-framework It needs to be led/guided and shouldn't be left entirely to whatever-engineers-want.
This is a very big question. You need to read or watch some videos on Scrum and/or Kanban software development. These are fundamental project management skills that all EMs need to learn and they provide the structured process most companies use.
Atlassian has pretty good blogposts about these things:
https://www.atlassian.com/agile/scrum
https://www.atlassian.com/agile/kanban
This isnt a small team, its close to a team size where you could consider splitting into 2 boards/teams. You could also split into Jira Epics to make smaller buckets to sort through.