My MSN special message often features something about “triage”, and one of my esteemed colleagues suggested I write a blog entry about it. “Not a bad idea”, thought I, “after all, many an onlien frenz has asked me what triage is”.
In medical terms, I am led to believe that the triage process involves finding a lot of almost dead people and deciding which ones should be saved with the limited resources you have. Software defect triage is similar to this, but slightly less traumatic. The idea is that you have a heap of issues (often called “bugs” or “defects” by non-Microsoft types) and you only have x amount of developers with n amount of time to fix said issues, so you’re not going to get to all of them and you want to make sure only the most important ones make the cut.
This is done in a number of different ways, in varying situations, but I may go into that in a later blog post. For now, I’m going to tell you the best way to approach a triage if you’re doing one on your own. The scene: you’ve just been put on a project and some manager has decided to put you in charge of “triaging” all the issues. There are about 300 of them. They are assigned to various random people. What do you do?
Well, here’s what I did.
1. Go through the list and cull out any duplicates. Usually this requires you to have a pretty decent memory, but sorting by name or category often helps. Once you’ve done an initial cull, I find that doing the other triage steps usually burns most issues into your brain so you tend to spot duplicates pretty easily after that.
2. Go through the entire list and find anything that is unclear and assign it to someone to get it clarified. It helps to separate these in some way, either by moving the issue to another issue tracker or sticking “CLARIFY” to the subject line so you know what’s going on with these issues.
3. Look for any issues that seem too “nitpicky” and do your best to get them off that list (e.g. “Table is 2 pixels too wide”, “Button is a different shade of green to other button”, “Use of capitalisation offends me as a woman”). Go back to the person that raised the issue and explain to them why their issue “doesn’t make the cut”. This is step 3 because by this time you will have the expression of someone who has just spent a month searching cow pats to find gold teeth. People don’t generally argue too much with a face like that.
4. Comb the list for issues that are “borderline” – the sort that seem pretty nitpicky but the person raises a valid point for their inclusion (e.g. “This obscure error message isn’t user friendly enough. What if it appears and the user doesn’t know what to do next?”). Go to the person who raised the issue and argue like hell to get it off the list. By then they’ll probably be a little scared of you anyway (see point 3) so you’ll have the advantage, so if they win you know that it probably really is important that it stays on the list and you should leave it in.
5. Get to know your team members’ strengths, skills and experience and reassign issues appropriately and prioritise them.
So your list should be pretty clean by now. When new issues come in, you’ll be wanting to do the following:
1. Determine a suitable set of cut-off rules for dismissing new issues, and communicate it to your team, so that your decisions to dismiss new issues does not seem subjective and arbitrary.
2. Teach your team how to look up existing issues so that they don’t treat your brain as their personal issue search engine.
3. Be aware of the workload of each developer so that issues are divided evenly among team members.