This was a random idea that came to me while the topic of support ticket priorities was being discussed on ifMUD. Someone has since asked me to post it, so here it is
( Read more... )
Except that all users consider their own bugs to be urgent/critical.
One idea I got while reading this post was that maybe all users have the ability to assign any level to the bugs they write up, and internally that field is "submitter's priority". Then when the bug is evaluated by the team responsible for the area the bug is in, they assign their own priority "engineering priority". Then there's a third, called "marketing priority" which allows the marketing group to indicate to engineering what bugs are standing in the way of making sales.
Then of course there's "customer priority" which is for when multiple customers run into the same problem, and are willing to pay (or are already paying via service contracts) for fixes.
Then the engineering team looks at all the bugs and all the priorities assigned to the bugs to decide what's the most critical. And then the individual team members work on whatever they think would be the most interesting or fun to do.
You only need three priorities: 1) stuff that has to be fixed immediately 2) stuff that has to be fixed, but not immediately 3) stuff that isn't actually going to be fixed (you don't technically need #3 but people feel better having a place to put it instead of not filing it).
We actually have a similar situation as what markm pointed out.
When we file a bug, we have to put two values in - one is a priority, Critical/High/Medium/Low to indicate how we feel this should be fixed. Then we have a value that's called User impact - this reflects how this is for the user. and that's Massive, Major, Moderate, Low. And so you might have something that's Critical on the priority, that it needs to be fixed yesterday, but the actual user impact is Low, because they might never see it. There's no separate marketing priority, but we generally lump it in to the user impact.
It works pretty well for how the dev team figures out what needs to be done next.
And we have a different type of ticket for a "would be nifty to have" than a bug, which is different from "i want this feature"
Comments 5
One idea I got while reading this post was that maybe all users have the ability to assign any level to the bugs they write up, and internally that field is "submitter's priority". Then when the bug is evaluated by the team responsible for the area the bug is in, they assign their own priority "engineering priority". Then there's a third, called "marketing priority" which allows the marketing group to indicate to engineering what bugs are standing in the way of making sales.
Then of course there's "customer priority" which is for when multiple customers run into the same problem, and are willing to pay (or are already paying via service contracts) for fixes.
Then the engineering team looks at all the bugs and all the priorities assigned to the bugs to decide what's the most critical. And then the individual team members work on whatever they think would be the most interesting or fun to do.
Reply
Reply
Reply
Reply
When we file a bug, we have to put two values in - one is a priority, Critical/High/Medium/Low to indicate how we feel this should be fixed. Then we have a value that's called User impact - this reflects how this is for the user. and that's Massive, Major, Moderate, Low. And so you might have something that's Critical on the priority, that it needs to be fixed yesterday, but the actual user impact is Low, because they might never see it. There's no separate marketing priority, but we generally lump it in to the user impact.
It works pretty well for how the dev team figures out what needs to be done next.
And we have a different type of ticket for a "would be nifty to have" than a bug, which is different from "i want this feature"
A bit convoluted but it works fairly well.
Reply
Leave a comment