Jira Isn't as Bad as I Thought

I used to hate Jira with a passion. And I still dislike Confluence, see my rant. But lately I have realized that most of my hate actually comes from my misunderstanding of it. It turns out to be quite the useful tool, but you need to have the right use case for it. Otherwise it will be plain agony.

For all my open source projects, I just use GitHub to host them. And there I also have the “Issues” feature, where one can track bugs and ideas. GitHub Issues are really simple, they just have two states, “open” and “closed”. They don't have much metadata, they have a free-form Markdown field. You can optionally add tags, add a milestone and assign multiple people to each issue. When it is done, it gets closed. There are two tabs, one for open, another for closed issues. In the search one can also include the closed tickets.

This makes GitHub Issues really easy to start with. One can just create an issue, write a single sentence for the body and leave it there. There is no need to assign it to somebody, no need to triage. For small projects, the number of open tickets is very small, so there is great overview. And because the closed tickets get hidden in the “closed” tab, they don't clutter the main view. It is easy to figure out what to do next.

First contact with Jira

With Jira, that is completely different. When one opens a project, one sees all the tickets, including the closed ones. And the view isn't a compact list, it is a really rich column and you can see the details of the ticket in another column. It feels like an e-mail client with a multi-column view. This might be nice to see the details of a single ticket, but I don't find it easy to navigate. And since all the closed tickets are there as well, it is hard to find the next task.

When one opens a new ticket, it has a lot of fields to be filled in. Most are optional, but one has to choose a type of issue, like “bug”, “improvement”, “task”. The text has to be entered with the Jira syntax, not with Markdown. This is annoying. Ater having created the ticket, it will in a “draft” state. Then one needs to click “finish draft” and it will become “ready”. Then one clicks “start work” and it will ask for an assignee and also for a comment. After that it will be “in progress”. One cannot just close the ticket then, but instead has to do another transition (with comment) to “in review”, then to “in QA” and then “ready for release” and then it can be marked as “done”. What the hell?

After having that experience, I didn't understand why anyone would voluntarily use Jira, and I have tried to avoid it as good as I can. It just seems like a waste of time. I have much preferred GitHub Issues, as they seem to much simpler and clearer. Maybe if one has a really strict burocratic development, it might make sense to have all these intermediate states, and also have different people write a comment. But then you basically have to have a manager who manages Jira every day.

Todo lists

To organize my personal life, I used a simple todo list. I had used Toodledo, which gives you a table of your tasks, with columns for project, context, priority, and so on. This felt good for a while, but I grew frustrated with it. Now I use Todoist, which lets me schedule tasks for a given day, and then I try to get it done on that day or later. But for software development, I very often have things which are stuck on something. So they are in progress, but I cannot continue with them at the moment. And they might be done, but somebody else has to test it. Or I have the idea, but it is not developed enough to start working.

I tried to do that with Microsoft Todo, but there one can only mark tasks as “important” with a star, but that's it. It doesn't have priorities. One can define nominal categories, but they are not ordinal, so these states are just colors or words, but they have no order. What has frustrated me the most is that I usually have lots of tasks in there. And I have a desire to finish them to have an empty list. That makes sense in personal life, because after all the chores you have free time. At work, I don't want to have free time, I want something to do at all times. So it is good to have a long list of things that could be done.

I ended up hacking a Kanban board by abusing it. I have created multiple lists, named “Backlog”, “Planned”, “In Progress”, “Almost Done”. And I would just drag the todo items between these lists. This would make me a bit calmer, because everything in the backlog would not crush me, but instead I would think of this as an idea repository, where more items was better.

After having used this for a few weeks, I realized that I quite love the Kanban way of working with tasks. Having a huge backlog doesn't stress me out. Each morning I can just go through the backlog and pull things into the “Planned” list, picking a few items. Then I pick one of these into my “In Progress” and work on that. I only plan to finish the planned items.

The problem with this approach is that it doesn't work so well once one shares a project. One would need to share four lists per project. It just feels wrong. So I looked to create a GitLab Board. And then I realized that all those intermediate states in Jira make sense, when one thinks of this as columns in a Kanban board. One would just pull the tickets along the columns of the board (along the swimlane). It is just that there is so much friction with Jira.

Back to Jira

Still I was supposed to use Jira, so I thought to give it a try again. If it turns out good, I will have a nice tool to work with. If it turns out bad, I could write a bitter rant about it. Either way, I'd get something nice out of it. And in the end I got a mostly nice tool.

Jira also has boards. But one cannot just use them. While trying to get it to work, I learned enough to navigate it. My mental model of Jira now feels congruent with what it actually does. It doesn't surprise me any more, and I understand how to operate it. Now it doesn't feel like working against a stupid tool, but rather using it correctly.

As I wrote before, the project view shows all the tickets, even the closed ones. This is not the view that you want to work in. One creates a filter, using the Jira Query Language (JQL). I have for instance created a filter which takes all the issues from my “component” (sub-project), which are not done. This gives me just the tickets that I need to work on eventually. This filter is then saved with a name, say “my component open”. These named filters also appear in the navigation and let you go to a view.

In GUI applications you usually have the model-controller-view approach. The data is stored in some database according to a data model. Then the controllers manipulate the data and prepare it. The view displays the gathered data. This separates data model and views, to allow for all sorts of controller logic. This might feel overly complex for simple problems, but it allows the flexibility for harder problems. And Jira is the same, it has an underlying pool of tickets, and one creates certain filters, which are then displayed in various views.

With the filter prepared, I can create a new Kanban board. It will ask me for a named filter and then automatically creates a board from these tickets. So the tickets don't live in the board, but the board is just a view onto a subset of the tickets. With that point of view it really starts to make sense. And it also makes sense why one cannot just create a board.

In a board, one maps the various statuses to columns in the board. One can also have multiple statuses in one column, though I would not recommend that. Once one has this set up, the issues are automatically sorted into the columns. They can be dragged into other columns. Jira still asks for an assignee when one puts into into “In Progress”, but now that makes sense. One just clicks “assign myself” and it is taken care of.

Their board even has the option to separate the backlog into a separate view. This also makes sense, because the backlog is much longer than any of the columns. There I usually don't want to have more than five tickets in each column, but the backlog easily reaches 100 items. The Jira backlog view is a really compact list, which is great to navigate.

And then I'm happy that it has priorities, such that the backlog can be sorted in a sensible way. One can also add milestones, releases and various other things to organize. And there is one even more complicated way to use the board, namely as a sprint board where one defines epics and sprints. This then lets one use it with SCRUM, but I am happy with plain Kanban at the moment.

Another thing I didn't realize at first is that Jira is customizable. This is not apparent to the user, because they don't have the admin permissions. The “workflow”, meaning the transition between these states, can be defined at will. One can remove stages which aren't relevant, one can allow skip connections between states. This way one can drop it into any column of the Kanban board at will.

Once one has all this, one can even create dashboards with custom filters, see how many tickets are in certain states, create pie charts with the assignees of tickets, and so on. And with the underlying data model of a ticket pool, it makes sense that all these things are available.


Jira isn't that bad, after all. It is just a very complicated tool. And it is not self-explanatory, one needs to figure out the relations between tickets, filters and views. One needs to form a rich mental model with multiple layers to really understand what is going on, and why some of the things feel so complicated.

The major issue then is that it doesn't scale down in complexity. It cannot scale down to the level of GitHub Issues, so it is complete overkill for simple projects. It only makes sense for larger companies. New users have to be onboarded, otherwise they will end up hating Jira, like I did. If you need to have a complex representation of a complex workflow, Jira seems capable. From my perspective it will be able to scale up quite a bit more than what I have been using now.

It feels weird to say, after that deep hate that I had, but I am actually looking forward to work more with Jira and tell other coworkers how to use it effectively and without frustration.