The trouble with "High Priority"
[This is a long rambling rant -- you can stop reading now]. If you're bug tracking software lets you say that every single bug in the system is high-priority, then it's meaningless. You may as well say everything is low priority. The answer isn't to have more granular priority levels (super urgent, semi urgent, sorta urgent and so on). To make a priority feature work you have to go holistic and look at the context of the bug...
Priority is so damn tricky and yet so simple:
Bugs doesn't exist in a vaccuum -- they exist alongisde other bugs/tasks and there are people who are going to do those bugs. If you're serious about settings the priorities for a series of bugs then you need to re-sort the bugs for a particular developer (possibly yourself).
"This one is the highest priority for Jack to work on, then that one, then that one."
You don't need to go down too low. A strict rank order is only useful for the first few. Assigning priorities to the lower order tasks is just 'busy work' that makes you look busy when you're really just shuffling papers. By the time those tasks rise to the top, other things will have come into the system anyway.
At Advantech Software (Brisbane's Premier .Net Consulting Specialists, ;-) we use FogBugz, from Joel Spolsky, and we're very happy with it. It's even begun to influence our language. We now say "I'll raise a foggy" anytime we either find a bug, or decide on a task, or invent a new feature.
But even fogBugz has the traditional 'priority' problem, much like every piece of bug tracking software I've ever used. Maybe a bumptop style solution would work? It's like the weather you know; everyone complains about it, but nobody gets in and fixes it.
Another feature I'd find useful is the ability to split one bug report into many bugs. And to split one feature into a series of tasks that make up that feature. Customers email in these documents that contain fifty different problems. And on a different track: simple features soon turn out to invole implemening many little steps along the way, each of which can be assigned to different people. (Let the bomb expert make the bomb, the safe cracker can crack the safe, the disguise expert can... and so on). This kind of hierarchy work quickly leads to usability problems. A feature rich interface can become impossible for any new user to pick up, and smart software does well to avoid it. An overly complex bug tracking system is worse than none at all.
Okay, just blogging this rather than emailing it to Joel Spolsky. Do you know he tends to personally respond to all his emails? I find that pretty amazing, as he's a busy guy. The technical support at technorati, by contrast is hopeless. How come they say I haven't updated my blog in 353 days when I update it every week? I've done the 'update ping' thing, but nothing works. If anyone can solve this for me I'll send them a robert scoble style link in gratitude.
'engtech' on Fri, 27 Oct 2006 06:26:40 GMT, sez: Full agreement on priority. It's so misused and becomes completely arbitrary.
I had the same Technorati problem as you. As far as I can tell they only have one person working tech support.
The link to my account of it is here: http://engtech.wordpress.com/2006/10/20/technorati-top-10000/
You could try the same think that I did: delete your claim and then reclaim your blog. Except it didn't work for me, all it did was escalate my support request (went from no update to no claim) so I got a response :)
What probably happened is they marked your blog for "review" (that was what they told me -- maybe someone reported you as a splog?) and that keeps it from updating.
'Matt' on Fri, 27 Oct 2006 07:00:01 GMT, sez: Interesting comments.
We use Jira (http://www.atlassian.com/software/jira/) which lets you dice up your issues (which is Jira parlance for a bug/ticket/foggy(?)) further into individual tasks, each of which is a fully fledged issue, but which resides beneath another issue.
It works quite well, as you can monitor progress through the issue on a task-by-task basis. You can also clone/link/relate issues, so an issue automatically created via email with, say 10 issues, can be split into individual issues. Your CSR can monitor the automatically created issue, until all the linked issues are finished, then respond to the client (or whatever).
Does FogBugz have anything like this?
'stuinzuri' on Fri, 27 Oct 2006 09:05:22 GMT, sez: Agreed. I have in the past written DSS stuff to report priority assigment statistics...and demand that my users balance them out. Lords of Kobal, they hated me for that!
Stu
'Locutus of Borg' on Fri, 27 Oct 2006 09:06:57 GMT, sez: Trust me, Joel Spolsky does NOT answer all his emails personally.
'Martin' on Fri, 27 Oct 2006 12:53:16 GMT, sez: Try flyspray (http://flyspray.rocks.cc/), free and can do a lot of these things.
'Wesley Shephard' on Fri, 27 Oct 2006 15:58:07 GMT, sez: There are a couple of options.
1. We do monthly releases and weekly goal sets. That means that "urgent priority" means it is in the next weekly goal set. Too big for a weekly goal? Well, you need to subdivide it then anyway. "High priority" are those for the monthly release. Everything else is normal priority, except the "dream" items which get "low" or "very low" to keep them out of our vision.
2. The other option I have considered is a priority scheme where you can raise or lower the priority *relative to others*. So the top item gets assigned priority 1, the next 2, etc. If you want to raise an item, you have to insert it above something else, pushing all those other items down. Obviously the PM needs to be responsible for that priority order.
'bjorn' on Fri, 27 Oct 2006 17:19:32 GMT, sez: Anyone know if there is any plugins/extensions to Team System that gives it any _features_? I've been using the Scrum thing that gives you Sprints and Product- and Sprint backlog items, but it's still using those Query based views that can't do anything useful.
'Patrick from an IBank' on Mon, 18 Dec 2006 11:29:44 GMT, sez: for us, Urgent/Critical are emergency bugs where business cannot continue.
High is very high.
Medium are the majority.
Low are the "it should be in Bold font issues"
|
secretGeek .:dot Nuts about dot Net:.
Just Wally
Complete secretGeek Archives
The Best Software Writing I
The Business Of Software (Eric Sink)
