In part one of a three-parter Ian Mellor, EPIX’s Technical Director, explains how we triage the queries, issues and requests that MARKUS users send us.
A few of our customers have been asking about how we plan our work, and particularly where the long list of ‘lower’ priority requests end up in our long term development backlog. So, welcome to part one of a three part series that explains how we prioritise work for the development team at EPIX, and how we work through customer problems and requests.
This first post covers how we categorise and prioritise issues, a process we call triage. We borrowed this name from the medical world where triage is ‘the preliminary assessment of patients or casualties in order to determine the urgency of their need for treatment and the nature of treatment required’.
Our Issue Tracker
Every request or question that we receive from a MARKUS user ends up in Jira, which is an project management and issue tracking system. Jira is the single point of truth at EPIX. For a while we experimented with implementing a special version of MARKUS to track ‘issues’, but whilst we know a lot about repairs and maintenance, it turned out we didn’t really know how to monitor and track projects. In the end we looked at tools that other people had produced and, after experimenting with a few, we came to the conclusion that Atlassian’s Jira gave us all the features we knew we needed – plus a lot of clever features we hadn’t even thought of!
Whether you call us, email any of the team, leave a message with Moneypenny, or email directly to your support address, if we can’t answer or solve your question immediately the issue will be added to Jira to be triaged. This process quickly identifies the type of request, the urgency of the request, and its importance.
The Nature of the Issue
We have a number of issue types within Jira for requests, as outlined below. Many different actions might need to be taken after an issue is raised and we find it useful to categorise these to make sure the right people are involved. This also helps us to communicate internally on the best way to respond.
User Guidance – this is for anything where we’ve taken a question from a customer, and given direction on how to resolve it. Sometimes these issues start off sounding like bugs, or problems with the system, but once we’ve understood what a user is trying to achieve we can often guide them in the right direction quickly and easily.
Bug Fix – there’s always the odd one that sneaks through.
Correcting user input – sometimes people have instant regret for something they have just setup or changed, and need help putting it back to how it was.
Mobile Connection Problem – we gather these in one place so that we can easily categorise them and spot if there is a consistent problem.
Problem with 3rd Party – this is where integration problems end up if the client’s system is having a problem, and also where your own internal network and configuration issues sit.
Server Down – an extremely rare event, but we log this type of issue separately so we can report on them and closely monitor any deep problems.
Quote – hopefully self explanatory!
Providing Words to Customers – we get asked for help with tenders and proposals on a regular basis. We stash all these questions as the same issue type because often we’ve answered the question before. We have a pool of about 200 previous responses we’ve worked on that we use as inspiration.
Add on Sale (Coding) – big and exciting changes for a single customer.
Add on Sale (Non-Coding) – for extra assistance over and above our normal support.
Implementation – for new customers we have implementation and training tasks.
Customer Relationship/Project Management – another self explanatory issue type.
Approach to be decided – if we can’t work out how to respond or change something in our regular planning meetings then we put the issue to ATBD so that we can do a thorough and in depth proposal. Often this is just an internal discussion before moving on to coding a change.
Free-of-charge Task – sometimes it is easier for us to JFDI rather than trying to explain the solution, or we have a magic way of doing something that would be really hard for a regular user of the system to do. Those tasks end up here.
Coding – all the changes that we think would advance the product, or be useful for a range of customers, not just the customer that’s raised the issue.
These last three are where most of our long term issues live – if we’ve had a request that’s a great idea, and probably isn’t worth charging for, or where there’s no obvious bug that needs fixing, then we normally prioritise the other issues ahead of them.
Here’s a breakdown of issues received in June 2024, which was a fairly typical month.
Urgency
Once-upon-a-time we had our own service level agreements (SLA’s) that were hidden in our standard terms and conditions – they were vague and confusing. About 10 years ago Mike tripped over an article from Google discussing their policy, and we thought it was so good that we pinched the concept. Over the years since then we’ve morphed it a little bit:
P0 – needs to be addressed immediately
P1 – needs to be addressed quickly
P2 – needs to be addressed in a reasonable timescale
P3 – should be addressed when able
P4 – should be addressed eventually
The first ‘priority’ that we have, the P0, we use if there’s ever a severe problem causing one (or more) of our customers to be unable to work. This is reserved for server outages or database problems. These are thankfully few and far between, but we throw all our resources at these sorts of problems, and everyone at EPIX jumps on the phones to keep our customers informed.
We used to refer to P1 as ‘24 hours’ and ‘stopping someone from working’, but over time we realised that this often confuses more than it helps. We aim to respond to all requests, even ones that end up as a P4, in as short a timeframe as possible, so it was silly to have a concept of ‘respond by’ or ‘first action’. After reading about how Google prioritised work, we introduced the P1 as a way to report on issues that we would work on until it was fixed, and allocate someone to do it straight away. Most of the time this priority is used for the User Guidance or FOC Tasks issue types, because the person who is calling us with the question can’t carry on working until we have answered it – and most of the time we have solved their problem before we hang up the phone. The other major issue type for a P1 is a Bug Fix – we don’t like bugs, and like to squash them as quickly as we can.
The distinction between a P2 and a P3 is more nuanced – normally a P3 is something that we will plan to do, have agreed with a customer, and give a firm commitment to. This includes large items of work, major changes, and paid development. A P2, on the other hand, is something that is affecting a couple of users but not stopping them from working because there is an obvious work around. P2 issues sometimes hang around for longer than we would hope because the problem is small, and the work around is easy, and nobody is championing the issue.
The final priority, P4, is reserved for issues that we think are a good idea, that someone has asked for, but nobody is really chasing. We don’t have a lot of these.
Here’s June 2024 again as an example:
Priority | Count |
Closed immediately during triage | 37 |
P0 – needs to be addressed immediately | 1 (thankfully!) |
P1 – needs to be addressed quickly | 193 |
P2 – needs to be addressed on a reasonable timescale | 66 |
P3 – should be addressed when able | 41 |
Total Result | 338 |
Importance
This is the last thing we determine about an issue before working to resolve it – and the second article in this series will look at what we mean by importance, how we schedule the work within the team, and how we allocate resources to push the product onwards.
I hope you found this insight interesting, I’ll be back soon with part 2.
