Ticket Statuses: A Complete Guide

No matter what kind of ticketing system you use, understanding your ticket statuses is critical to being efficient. Knowing what's happening with a ticket and what might happen next is the entire point of your ticketing system. Just as important as one person having that understanding is the entire team sharing that understanding. In this post, we'll go through a list of potential ticket statuses your system might provide. 

It's important to recognize that every team might not need every ticket status and that every system might not provide the same statuses. This guide will cover a variety of statuses you might use and explain what they mean and how you might use them. But if your ticketing system doesn't provide a particular status, that doesn't mean you should abandon it. Tailor your ticketing system to your team's usage. 

What Is a Ticket Status?

In short, the purpose of a ticket status is to provide an at-a-glance guide to what's currently happening with that ticket. The "at-a-glance" part of that sentence is key. With a quality ticket status, you shouldn't need to dig into a ticket to know what's happening. Statuses are used to communicate across an organization, and a ticket's status should be clear not only to the people working on the ticket but also to outside stakeholders and even to customers who opened the ticket. 

What Ticket Statuses Should We Have?

As we walk through ticket statuses, our goal will be to trace a hypothetical ticket through the entire ticketing flow. We'll start with the status a ticket might have when it's first opened and end up closing the ticket by the end. Not every ticket will take the same path, and as we noted, not every ticketing system will have the exact same statuses. 

Backlog

Backlog is usually the status a ticket will start with when a user first opens it. It might also be Planned or Unassigned. The key thing to understand about a ticket with this status is that no one is working on it and that no one plans to work on it right now. For some tickets, this is the only status they'll ever have. Many teams have much more work than they'll ever be able to complete, and they'll keep tickets in the backlog that they never actually work on. 

Many software teams will regularly undertake a ceremony that they call backlog grooming. The goal of a grooming session is to examine tickets on the backlog and determine if they're still organized in the correct priority order. Backlog grooming also involves making sure all tickets have the necessary information. 

"The key thing to understand about a ticket with this status is that no one is working on it and that no one plans to work on it right now."

Staged

The next phase a ticket might move to is the Staged phase. You might also call this phase Assigned. If yours is a sprint team, these tickets might be in the next sprint. A ticket in this phase is ready to work. All the required information is present, and the team or user that will work on it knows how to finish it. At this point in the ticket's life, nobody is actually working on it. However, the customer has a clear picture of when work will start, and teams know how they'll plan to work on it. 

If you're working on an agile software team, the team might not assign Staged tickets to employees. Other teams may choose to assign all tickets when they stage the ticket. Which direction to take this status is up to the team. 

In Progress

Whether you assign a ticket to an employee before you stage it, the next step is to start work. Ideally, this work will proceed straight toward a satisfactory conclusion. For instance, if your ticket is something like a simple account unlock, you might finish in a few moments. Other tickets might stay in the In Progress state for weeks before the team finishes them. In the worst-case scenario, I've seen tickets that remained in progress for months at a time. 

Once a ticket moves to the In Progress state, there are a few different ways it might go. We're going to trace all of those different options from here. 

In Review

Whether your team has an In Review state likely depends on how you work. The In Review state is most common with software teams, in my experience. This usually means that the primary work for the ticket is finished but also that the person who did the work is waiting on input from someone else before they close it. Code review provides many benefits for software teams. For other teams, a review state might not make any sense. With our hypothetical account unlock ticket earlier, there's no need for a review. 

This is the happy path for our ticket: moving from In Progress to In Review and then ideally to Closed. Unfortunately, there are a few unhappy paths we need to address. 

Blocked

This is one of the unhappy paths a ticket might take. A Blocked ticket is the type of thing that most teams do as much as they can to avoid. When a ticket is Blocked, it means that the team currently assigned cannot work on it for some reason. While most teams do try to avoid Blocked tickets, they're a cost of doing business. Usually, a ticket will be blocked because the employee assigned to it is waiting for more information or for some work to be finished by another team. 

When a ticket is blocked, it's imperative that the ticket contains information about what is blocking progress. While this violates our initial rule about ticket statuses being useful at a glance, this documentation is still critical. When you clearly document why a ticket is blocked, it keeps everyone on the same page. 

Closed (Won't Fix)

Closed (Won't Fix) is another unhappy path a ticket can take. This status is reserved for situations where a ticket simply won't ever be worked on. There are all sorts of reasons you might not want or be able to work on a ticket. It could be that the ticket's request isn't a priority for your organization. It might be that the ticket was originally useful but had a hard deadline that has passed. For whatever reason, you've closed the ticket, and you communicate that you will not address the request. 

Closed (Fixed)

Closed (Fixed) is the end of our happy path. Your team completed the assigned work, and you've communicated that to the customer. The ticket is finished, and no more work needs to be done. 

Wrangle Will Help Your Ticket Status Management

Wrangle integrates with your ticketing system and Slack. By bringing your team's ticketing system and your primary communication platform together, communicating status changes is simpler and faster. Every time a ticket moves from one state to another, Wrangle alerts your team in Slack and automatically sends the message to everyone involved. You can also take steps like turning individual Slack messages directly into tickets and updating tickets from Slack. 

As we've talked about the importance of ticket statuses here, we've made it clear how helpful it is to make sure that each ticket is in the correct status. Wrangle makes status management easy, which makes finishing your work easier too. 

This post was written by Eric Boersma. Eric is a software developer and development manager who's done everything from IT security in pharmaceuticals to writing intelligence software for the US government to building international development teams for non-profits. He loves to talk about the things he's learned along the way, and he enjoys listening to and learning from others as well.

‍