You can't tell too much from this graph, like you say in your essay sandal -- this could be the sign of a vibrant bit of software that's got exponential growth in users and subexponential growth in issues (nice!)<p>An issue tracker will never replace a great product manager; the most important thing is to make sure the team is working on the most important things.<p>If urgent (actually urgent, e.g. critical fixes) things are taking all the time from the important things, then you have more work to do; maybe in prioritization, maybe in staffing, maybe in architecture.<p>Anyway, if you have this graph, and as you say, everything is on fire, then I would, if I were put in charge of this project:<p>1) Spend at least a half day skimming/reading all open tickets, and seeing what tickets each developer is closing<p>2) Meet with the team to see how they're prioritizing work<p>3) If the team has good intuitions about choosing their work, I would decide on the most important task, make sure it's on post-it notes around the office and on every monitor and tell the team: choose your issues, but make sure they always are absolutely the most effective and efficient way to push forward what's on the post-it note. Once that item was done, we'd pick a new one.<p>If the team has bad intuitions on choosing work, I'd probably take over task assignment until I trained / found at least one senior dev who could do some of that work.<p>If all the bugs are critical errors, e.g. not feature requests, but problems with the code quality, well you have another project in front of you, and one that most likely involves some staffing changes.<p>I'm looking forward to your review of what you did, and how it went!