A periodic part of my job is to trawl through the backlog in JIRA and reject tickets that a) have no acceptance criteria b) have had no activity at all for 3+ years c) have been completed under some other ticket (it's amazing how often this happens!) d) are no longer reproducible as issues (often because the product changed so the original ticket is irrelevant).
My goal is to never allow the backlog to exceed 100 tickets (I wish it never exceeded 50 or even 30 but hey!). When I first started working on the frontend team's backlog, there were over 400 tickets -- we're closer to 100 now :)
It's annoying, frustrating work but I think it is extremely valuable in terms of morale and "hygiene".
You're right about the difficulty of convincing project management to put constraints in place ahead of time. Like everyone else, that's not how they've been trained to think.
Maybe it's worth it to have constraints in the code process itself. "If this feature requires more than two model changes, increase the time estimate." Or the venerable, "No method may have more than 25 lines. If it looks like it must, increase the time."
I harp on time because that's a consequence that everyone can see. In a scrum system, increasing time decreases deliverable points. It automatically forces some of those trade offs.
But no, I don't think this is adequate for what you're describing either. It's an entire paradigm shift. Quite a problem.
A periodic part of my job is to trawl through the backlog in JIRA and reject tickets that a) have no acceptance criteria b) have had no activity at all for 3+ years c) have been completed under some other ticket (it's amazing how often this happens!) d) are no longer reproducible as issues (often because the product changed so the original ticket is irrelevant).
My goal is to never allow the backlog to exceed 100 tickets (I wish it never exceeded 50 or even 30 but hey!). When I first started working on the frontend team's backlog, there were over 400 tickets -- we're closer to 100 now :)
It's annoying, frustrating work but I think it is extremely valuable in terms of morale and "hygiene".
Reminds me of the more extreme https://x.com/r00k/status/1147903699513204736!
You're right about the difficulty of convincing project management to put constraints in place ahead of time. Like everyone else, that's not how they've been trained to think.
Maybe it's worth it to have constraints in the code process itself. "If this feature requires more than two model changes, increase the time estimate." Or the venerable, "No method may have more than 25 lines. If it looks like it must, increase the time."
I harp on time because that's a consequence that everyone can see. In a scrum system, increasing time decreases deliverable points. It automatically forces some of those trade offs.
But no, I don't think this is adequate for what you're describing either. It's an entire paradigm shift. Quite a problem.