Set the scene
Pretend you live in a very small town with just one fire hydrant. It is directly in front of a boutique that sells lamps.
One day a nearby building catches on fire. So, the fire department rushes to the scene, plugs into the hydrant, and gets to work putting out the fire.
When parking, the fire department accidentally also blocks the entrance to the lamp store; customers can’t enter and the store can’t receive deliveries. Upset at the disruption to their business, the shopkeep would like the fire trucks to move.
In this analogy, the shopkeep is your customer and the firefighters are your developers.
The trucks blocking the shop’s entrance are literally a blocker as the shop cannot conduct business until this has been removed.
However, your firefighters are busy making sure the next block doesn’t burn down.
Decision time
At DevRev we use separate objects to track what customers are experiencing (tickets) and the work that needs to be done to improve that experience (issues).
Tickets have severity levels: blocker (no work can progress), high, medium, and low (nice to have).
Issues have priority levels: P0 (highest), P1, P2, and P3 (lowest).
Your customer the shopkeep would have a ticket that said the fire department’s vehicles are blocking their store entrance with a severity level of blocker.
Your other customer the residents of the building that is on fire would also have a ticket with severity level of blocker stating there is a fire as the fire is blocking them from living safely in their homes.
Your developers, the firefighters, have a number of issues to address these tickets.
While both tickets are blockers, the issues’ priority does not necessarily match the severity of the ticket. This is because tickets’ severity is determined by the business impact to that customer whereas an issue’s priority is determined relative to all other work that needs to happen to satisfy the requirements of all customer tickets in the system.
If conditions change, then priority could change. If for example it was an abandoned building and happened to be during the town’s annual lamp festival, moving the truck could be bumped up on the list with no immediate threat to human life.
However, if it was a large fire in a heavily occupied building and additional EMS vehicles arrived on the scene, (further blocking in that truck). New issues would be created for things like treating burns and smoke inhalation, then moving the EMS trucks which all would have higher priority than moving the original truck.
Bringing the topic back to software
You may have Customer A who is a large account with an SLA (Service Level Agreement) that incurs hefty penalties when breached and Customer B who is a smaller account with an SLA that incurs minimal penalties when breached.
They both report two unrelated business blocking problems which are filed as tickets with severity level Blocker. Your on developers get busy breaking these down into issues that need to be completed in order to solve these problems. Turns out each has three issues so six total. Unfortunately, you only have three developers so you have to make some tough choices. You don’t want to breach Customer A’s SLA so you assign all three of those P0 and the issues for Customer B’s ticket P1. Problem solved?
Maybe. But what if only two of the issues attached to Customer A’s ticket were required to get them back up and running and the third is more of a housekeeping task? In this case, this housekeeping issue’s priority can be lowered and creates space for one developer to start working on issues attached to Customer B’s ticket.
Conclusion
From this, we can draw a few conclusions:
- The separation of tickets and issues allows us to track what specific developer work needs to be completed (issues) to satisfy the customer requirements (tickets)
- The separation of tickets and issues allows us to prioritize developer work for maximum impact.
- Severity for the customer ticket records their individual needs and impact to their business.
- Priority for developer issues allows work to be prioritized for your overall internal business goals.
Seems simple, so why aren’t all decisions made in this way? Short answer is silos. Normally tickets and issues are stored in completely separate systems with front office working on tickets in a CRM and developers working on issues in a work management system likely with no or limited access to the tickets in the CRM for context.
This is why we built DevRev, a unified platform that aims to break down silos and equip users with the information they need to make the best decisions for the company.
