| You make a lot of good points, and I agree with most of them. The goal of the essay though is not to suggest that tracking issue count is a useful metric. Instead, what I'm suggesting is that if you see lots of stuff going wrong in a project (things that are clearly costing time and money, angering customers, etc.) and then you look at whatever issue tracker is in place and you see a pattern like this, it's a sign of a broken triage and prioritization process. It's so common for this to be happening that I've seen this in many different projects, and I think you're spot on when you say it's because an issue tracker wants to be so many things at once, and it rarely closely tracks value. But in crisis situations, people on the front side of the business feel like they're "doing something" to help customers and users by filing tickets and then continuing to ask for status updates for them, to fight for their inclusion in prioritization meetings, etc. Because this does not actually help anything, it actually ends up hurting things. The tracker ends up as a mediator that obscures or limits communication about the real issues, and without a change, that can be disastrous in a troubled organization. So... the point of the graph is more of a quick way to confirm that triage/prioritization is being done wrong, so that you can make a decision on how to fix that. And that's what I'll cover in the followup essay. :-) |