Organizing Tickets for OPS Teams — Part 1
Ticket management is one of those boring topics that comes up every now and again in OPS circles. A lot of teams that I’ve chatted with try to model their ticket management process after the development process using Sprints/Scrum. I’ve found Scrum to be limiting in an Operations setting. The amount of uninterrupted work that comes into the queue for OPS teams makes it imperative that your workflow accommodates and expects unplanned work. In this first of several posts, I’ll talk about how my team manages their work.
I should start with a little sales job on why you need tickets. It goes beyond just tracking your work. It’s about making your work visible to you and your team, but also to others around you who have a vested interest in what you’re working on and also when you intend to work on it. A Kanban Board can help to organize and communicate what the team is currently focused on. There are plenty of great posts about how Kanban works and its goals, so I won’t dive too deep into that. I’ll just highlight a few key points.
- Limit the Work in Process (WIP) at any one time
- Make sure all work is visible and has a ticket associated with it
- Work should flow left-to-right through the process
Limiting Work in Process
One of the key tenants of Kanban is to make sure you’re limiting the amount of work in process at any one time. The knee jerk reaction is to pull in more work to increase throughput of the team but it’s counterproductive. Little’s Law speaks to this particular phenomenon well. The best way I’ve found to limit WIP is to limit how many tickets each person can have in process at any one time.
For my team, we’ve opted for a maximum of two tickets per person in process. This allows engineers to hop between the tickets in the event their other tickets is blocked and it’s beyond the engineer’s ability to unblock it. This limit also helps us to gauge how many tickets we can handle at any one time in the input queue. (More on that later)
The Backlog
Like SCRUM/Sprints, Kanban workflows have the concept of a backlog. The backlog is a queue of work that you may or may not deliver. When it comes to the backlog, there are no firm commitments.
I’ve seen some Kanban boards where the Backlog is the left-most column on the Kanban board. Personally, I prefer not to display the Backlog at all on the Kanban Board, saving it for a separate board. The reason is that humans have short attention spans.
I want my team laser focused on the things that are in the input queue, because those are the things we’ve given priority to as a team. With the backlog visible, it’s too easy to see a ticket that someone thinks is important or should pop into the work queue right away. The problem with this self-prioritization? Something else stops getting worked on. I know we all believe that multi-tasking is a thing, but it’s not. This leads to missed commitments, more work in the queue than is necessary and confusion from your stakeholders as certain items seem to jump the line without explanation. (Mainly the work engineers prefer to work on) Removing the backlog from the primary working Kanban board helps to stop this from happening.
Another benefit to hiding the backlog is the amount of noise it reduces. Backlogs always grow. Even a well-groomed backlog can be intimidating to teams. You don’t want the crushing weight of expectations constantly in the face of the team. There’s no sense of progress when you see an ever growing queue to the left of your screen. Just think of your own personal to-do system and you’ll get that feeling of dread creeping over you. Protect your team from that feeling. Hide your backlog.
Prioritizing the Backlog
Now that I’ve safely hidden the backlog, my next step is to prioritize it. In my current role we use JIRA for ticket management which allows me to easily order the tickets in the backlog visually. The order updates a ranking value on the ticket which is how Jira keeps track of priority internally. Keeping the backlog ordered by priority makes it easy to select what gets worked on next. Of course priorities can change daily, so there’s a level of discipline that has to be enacted to keep the ordering honest and up-to-date. I prefer that new tickets get added to the bottom of the priorities list, which makes it incumbent on me to re-prioritize the ticket if deemed necessary. If tickets don’t automatically go to the bottom of the priority queue, you’ll find yourself in a last-in first-out queue setup, which will eventually starve all of your older tickets.
The Input Queue
With the backlog safely tucked away and prioritized, the input queue becomes the left-most column on our Kanban Board. The input queue holds all of the tickets that we’ve currently committed to for this iteration. What’s an iteration? For our team, an iteration is the cycle to which we make fresh commitments on new tickets. Every week, we try to commit to a new round of tickets to bring our input queue back to its maximum capacity. If we agree that we’ll commit to 10 tickets per week, at the end of the week we’ll replenish the input queue to get it back to 10. (Or sooner if we run out of tickets)
If you do a good job of keeping your backlog prioritized then it becomes really easy to populate the queue by just taking the top X number of tickets in the backlog and moving them to the input queue. Following this pattern, your input queue should also be ordered by priority. (There are several scenarios where that might not be true, which I will address in a subsequent post) Now your team members can begin pulling tickets from the top of the queue and beginning work on them.
The Columns
Each Kanban board has at minimum 3 columns that represent the phase work is in. They roughly fall into the category of
- To Do
- In Progress
- Done
For simple boards that might be all you need. For me I like to have a little bit more information about where a ticket is in the workflow. More columns means a better idea of where tickets might be bottlenecking when the team starts to slow down. But the more columns there are the more of a burden it can put on the team as they try to figure out the minutiae of where a task is. Unless there’s clear value in the column, avoid getting too detailed in the phases of a ticket. For my team we have the following columns.
- To Do
- In Progress
- Waiting For
- Needs PR Approval
- QA/Verification
- Done
The titles of these categories are pretty self-explanatory except for maybe “Waiting For”. This column is for tickets that are waiting on some sort of external information, time or action. For example, if we’re waiting for Saturday night because that’s when the approved maintenance window is, there isn’t much that the engineer can do to move time forward. The ticket gets moved to the Waiting For column until we can implement the change. (I could probably eliminate the Waiting For Column in favor of a flag status to indicate the ticket is blocked. More on that later)
Tickets will generally flow left-to-right on this Kanban board, showing progression towards being complete. Each phase is important (for my reporting anyway) with regard to where the ticket is in the process and how I can be of assistance. Do I need to wrangle people to get the PR approved? Is a ticket blocked waiting for someone to respond to an email? Has the change been released and we need another team to sign-off saying it’s complete? This flow gives me insight into where we’re at.
Something to keep in mind when you’re designing your workflow. You have to think about the data that you want out of the system, including reports you intend to run. That will ultimately drive how you structure your system. If you don’t intend on reporting or leveraging a status, then in my opinion there’s really no need to have a separate status. Each of these categories I’ve listed above were created to express something I wanted to be able to report on or have a quick status of. This applies to everything in your ticketing system, not just statuses. Labels, ticket types, components, tags, all these things should be driven from some sort of reporting you intend to do.
Wrap Up
When I set off writing this I thought I’d get it all done in a single blog post. But this will clearly be something I need to write about over several blog posts. In my next post I’ll discuss the various issue types I use as well as additional swim lanes that can help to add context to tickets.
