Jira, is a common tool used for coordinating, tracking, and managing work. It is both praised for its flexibility, and criticized for being an ill-exercised and overly confusing tool. My personal opinion lies somewhere in the middle. At best, Jira can be very useful as a tool to increase your team transparency, particularly if you take the time to set it up to match your needs. At worst, it becomes an unadulterated time sucker, consuming your project management time and providing little other value.
Transparency Breeds Autonomy
The point of tools like Jira is to foster better coordination, but when used effectively, it can be a tool that gives transparency into the health and progress of software teams.
Why is transparency important? Imagine that your boss asks you for a status of your project twice a day. That’s fun, right? Why not just point her to a Jira dashboard that answers her questions any time of day or night? Or design your workflow so that the information she looks for is very easy to visualize?
The more you can demonstrate that you have control over your own process and its outputs, the less oversight will placed over you. This is the power of transparency. It is also known as “managing your manager” which you can read more about here. Eventually, your management will stop micro-managing you, and you will get more latitude to make decisions. Have I convinced you that transparency is in your best interest yet? I hope so.
I have successfully used Jira’s board visualization to give cross-functional groups transparency on the progress of my engineering teams. As an example, I once wrote integration glue to make incoming Freshdesk issues automagically appear in Jira and in Airtable. The transparency it gave our teams was well worth the small effort required.
Our Jira Workflow
In this post, I will discuss how one of my previous organizations structured our Jira workflow around bugs. Visually, it looks like this:
At first glance, this might seem a little complicated. But let’s zoom in on it one piece at a time.
Bug Intake Workflow
It might not sound like a big deal, but the initial classification of a Jira bug is extremely important. If you put incoming bugs straight into a developer’s line of work, and that developer has just become first-line tech support. Put the bug straight into the backlog, and your backlog can get out of control fast. We elected to do it like this:
Explained in English, a bug always enters in Triage status. Since the bug is usually coming from a support system like Zendesk or Freshdesk, having a specific and well-understood state allows someone other than engineering to review and potentially even decide that the bug is not a valid issue. This goes a long way to ensuring that your engineering team is not directly mired in time-sucking administrative concerns. If the Triage person or team decides to ingest the bug, it goes into the backlog; if it is a severe problem, it goes into “On Deck” which means it is available to be picked up for work (for context, this workflow was used in a slightly modified Kanban model).
Development to Release Workflow
The core of the development process we followed was designed as shown below. 
A bug is considered “In Progress” when it is being worked by a developer; a code review transition is mandatory (Review/Verify status) which then transitions to a very transparent QA flow. In looking at the workflow board visually, we could clearly see when issues were entered into QA’s queue (the “Ready For QA” status), when issues were being tested (“QA In Progress”) and when issues were considered “finished” from a development standpoint (“Ready To Be Released”). Since our QA resources were contractors, we could see when we were fully loading them, versus when they were not needed. Finally, we had explicit statuses for general release (“Released”) and demo releases (“Released to Sales/Demo”). Eventually, we simplified it further by releasing to all environments uniformly. Eventually, the Jira “Done” status is reached and the bug is moved off the board.
End Workflow
Almost as important as actually fixing bugs, we used the following statuses to properly classify work that we would not be doing. I think these are the minimum that are needed in any workflow that requires even moderate transparency:
A bug would be closed as “Works as Designed” if it was based on a misunderstanding of how the system was designed to work. “Duplicate” would be used to close any bug that was already captured in the list of existing bugs. “Abandoned” was used to close – but still classify – bugs that we purposely de-prioritized.
Retrospective
In thinking about how we organized the Jira workflow described above, I think we did about as good a job as we could, given the time and resources we had. The QA workflow in particular gave us strong visual insight on issues moving from development and through QA. If I went back in time, I would have spent more up-front time designing to accommodate our sales/demo environments and corresponding workflow around them. Supporting sales and demo environments will be the topic of a future post.