Triaging is a critical step in the lifecycle of any piece of work. I touched upon it in a previous article, and here we go into it in more depth.

The term has a medical origin. Deriving from the French triager, meaning ‘to separate out’, it is best to imagine either a military hospital near the front (known to many as a MASH unit), or the Emergency Department of a civilian hospital. New wounded are brought to the unit at unpredictable times, in unpredictable quantities.

The initial processing of these new arrivals is urgent, and must be done quickly and efficiently; there are, after all, limited resources of medical care to go round, so what is available must be used as efficiently as possible, where you will get the most reward (lives saved) for the effort. To achieve this goal this the wounded are ‘triaged’, which means divided into three categories:

• the worst cases – they will die anyway. These ones should be made as comfortable as possible, but they are actually not the highest priority, as medical intervention will make no difference.
• the minor cases – they will survive anyway. Obviously these are not the highest priority.
• the ones where immediate action will make the difference between life and death. It is these that are the highest priority – they must be prepped for surgery (or whatever is appropriate) as fast as is humanly possible. Every second counts.

Thus medical triaging amounts to a quick prioritisation exercise. It is done on the basis of limited information (you can’t spend hours investigating each new wounded case, you have perhaps minutes or seconds), but you obviously can’t do it on the basis of no information. The skilled triager knows exactly how much information is needed to make the triage call; he gathers that amount (no more, no less), makes the decision, then the patient is moved on to the next stage of their care, and the triage team moves on to the next wounded person, until all have been triaged.

Note that the triage team does not administer treatment – that is the next step. In some cases, that next step might follow one second later, but it is still conceptually a next step, possibly performed by a different person in a different place. The triager has to keep going with the rest of the triage as their highest priority, because the next case could be even worse – until you’ve looked, you just don’t know.

Triage is therefore complete when every single new case has been sorted into the correct category, in other words when the untriaged count = 0. Note that even if the helicopter brings in just one single wounded soldier, you still can’t afford any delays in starting triage, since you have no idea what state that person is in. That single guy could be your top general, right on the boundary between life and death, and a lackadaisical triage process means the chance to save him could be lost.

All of this has parallels in the world of software development, except – hopefully – there’s less blood. Instead of wounded soldiers being helicoptered in to base, the raw material for triaging is new tickets. Starting as soon as possible after new tickets are created, the triaging itself means sorting them into their correct position in the priority-ordered list that is the product backlog. That ticket is then triaged and the triage team moves on to the next one, until untriaged count = 0, when triaging is complete (for now), and the next steps can begin.

The one disanalogy between medicine and tech triage is that a new ticket might not have enough information to be triageable – some people write absolute gobbledigook in new tickets, or barely write anything at all. In that case you send it back to source for more information, and try to triage it again when it returns. There’s no medical equivalent of that – you wouldn’t send a soldier back to the Front to get their wound explained more clearly.

What is the tech equivalent of the three medical triage categories above? One way to think about it is that you are choosing between 6 broad slots in the backlog for a new ticket. For each new ticket, you need to decide whether the right place for it is…

1. …right at the very top of the backlog, ie it is the most important thing of all. It is quite likely to be an emergency to have dropped in this position, so your team needs a way to deal with emergencies.
2. …a specific slot in the top quarter of the backlog. If so, pick the precise slot in this quarter with some care, as much of the work this high up will have been started already, and is progressing across your Agile Board. This new ticket might need some extra attention to get it to Ready for Dev quickly, and once there you might then put it right at the top of the R4D column, meaning it’s the very next thing the devs pick up whenever one becomes free.
3. …somewhere in the second quarter of your backlog. If so, don’t bother being so precise about exactly where in this section it drops – it’s likely to be a bit of time before this work starts advancing across your board, and the backlog will probably have been revised several times before that happens.
4. …somewhere in the third quarter of your backlog. Even less precision is merited here. Some of this stuff will never get built at all, frankly.
5. …somewhere in the last quarter of your backlog. Most of this stuff will never get built, and you should consider carefully whether this ticket is even worth preserving at all. If not, you are at the next option…
6. …the rubbish bin, ie the ticket is worthy only of being thrown away. Maybe it’s a dumb idea, maybe it’s not such a bad idea but there’s just no chance of this happening on any timescale that people remotely care about. Depending on what ticket management system you are using, you may actually delete it, or perhaps just resolve as invalid, or won’t fix, or similar.

These 6 choices are shown in the pictorial example below. In this case, a new ticket ends up being slotted into the bottom quarter of the backlog, option 5:

Once triage is complete (well done! untriaged count = 0), your next duty is to make sure all interested parties know of this triage decision, including whoever requested/created it. In some systems (eg Jira) it may be sufficient to add them as Watchers to the ticket so that they automatically receive email notifications of updates; in other contexts, other comms may be necessary. When these parties do find out how you’ve prioritised their work, they may be fine with it, or may vigorously disagree, but it’s best to have those discussions out in the open immediately, rather than to leave potential future conflicts stewing away in the background.

It’s in everyone’s interest – the team, suppliers, customers, stakeholders – to have a good triage process – there may be some horror lying in wait in that unopened ticket! The metrics around this process are a) ‘Triage Time’, the time it takes for newly created tickets to be triaged, and b) ‘Untriaged Count’, the number of tickets in the system that have not been triaged yet, and are therefore of unknown priority. The aim is to get both metrics as low as possible. Oddly, I have never seen the Triage process specifically called out as a key measure of how well a team is running, and yet in my experience there is a very strong relationship between being a good team, and doing the basics well – and triaging is one of the basics for sure.

In the next article we’ll examine the steps from ticket creation to triage completion in more detail. For now we can summarise the best practice lessons for triaging as: do it quickly and efficiently, don’t let untriaged tickets lie around, aim to get your untriaged count back to zero daily if possible, and let the concerned parties know the results of your triage as soon as you have done it. If you do all this, you’ll be one of the relatively rare teams that have a tight Triage Process, and you’ll have taken a big step towards becoming a good team.