Preamble

I use “Hack” in the noble sense of the term. The most commonly accepted translation is “tinkering”, so very far from the hooded guy behind a screen where lots of green lines scroll by on a black background. So I'm going to explain the unconventional use I make of Jira workflows. If you were expecting to find a trick to become a super-admin of the instance … move along.

Context

Jira is a must-have tool in the world of project management. It has managed to establish itself as the reference in many fields. And deservedly so! Flexible, customizable, reliable, very well equipped (reports, charts, plug-ins, connectors, …). It can quickly become the indispensable companion of a whole organization for tracking its activities. A true panoptic control tower.
However, one point of frustration I have often encountered in teams is the constraint of workflows. When scaling the product, the temptation is great to want to harmonize and minimally control its use. It can bring advantages, but often at the price of creating decision and administration bodies that inexorably grow heavier. 🤢

Hell is the flows.

It is not uncommon to find Jira workflows that took weeks, even months of work by many people to agree on something satisfactory. You then end up with things like this 😱:

Source: https://abhilashshukla.com/business/best-practices/jira-workflow-for-software-development-and-quality-analyst-qa-teams/

I'm not throwing stones at them, because it matches their way of thinking and Jira strongly induces this kind of solution. I myself gave in to that easy path when I was asked to set up teams. But eventually, I quickly ran into several limitations that made me rail against the tool.

• Setup complexity
• Process rigidity
• Lack of team buy-in
• Over-standardization
• Time-consuming administration
• …

You should know that, potentially, each Jira project can quite well have its own workflow, its own ticket types, its own priorities, its own rights and profile management, etc. The counterpart is more complex administration for each project and, for those who host their own instance — typically large accounts — performance is heavily impacted. Inevitably, faced with these limitations, especially the last one, a big effort of harmonization, but above all of limitation, is put in place. Which loses most of the advantages mentioned above.

My vision

I'm not saying my vision is the best, but after using and abusing this tool's possibilities, I always come back to something simpler and more adaptable. After yet another complaint about the flows in place, I took a moment of reflection to try to understand why this so promising tool is so hated and whether we might not turn the tide. And then I remembered the first of the values of the agile manifesto:

Individuals and interactions over processes and tools

And that's exactly the problem: we made Jira the alpha and omega of project management. Everything, or almost, must be tracked, noted, described, explained in it. All that to get pretty charts to adorn sprint reviews. To perfect this tracking, workflows are indispensable, with time logging, forced (and therefore meaningless) comments, multiple custom fields, etc.
Imposing a workflow on a team is, in a way, a sign that it isn't trusted to follow the processes. It is infantilized in the management of the ticket lifecycle. We therefore go against the good practice of empowered, self-managing teams.

We need to get back to the essence of this tool, which lets us not get lost in the product's progress, without frills, in a simple (KISS), fluid way. But for that, we have to make a radical break in how it is used, and workflows are on the front line. So let's do things right! Let's completely blow up these darn flows! 🤯

1st idea

It's very simple to set up and to use. It uses and abuses the “Toutes” (“All”) transition 😈

It's a special transition in Jira. It has no precise origin, but it opens the possibility of reaching the targeted step from any point in the workflow. Very useful for waiting or cancellation states since it can occur at any time.
Well, everything rests on this property! Let's make a whole bunch of statuses accessible all the time from any point of this non-workflow!

The result is, give or take a few details, a Trello (a product from the same vendor). 😜

I see several advantages in it:

• Easy setup (simplified administration)
• Evolves without impact on the existing (backward compatibility)
• Jira configuration of a single flow system for all teams (scaling)
• Full per-project flow customization via the task board (acceptability)

But it's not without flaws either:

• Many useless statuses, visible and accessible
• Easier “loss” of tickets if not mapped in the columns.
• Veeeery long transition menu in a ticket's detail view.

Personally, I find the balance tips very strongly toward the advantages side.
Very enthusiastic about this idea and recently catapulted into the role of Jira practices lead on my assignment, I toured the top brass to sell my idea. Let's just say it didn't unleash exuberant enthusiasm 😅
On the Jira administrators' side, they were circumspect about the idea, because it went completely outside the box. On the managers' side, I was gently reminded that certain metrics still had to come out of Jira and that certain steps had to be mandatory to get some reliable data.

2nd attempt

So I went back to my drawing board to best satisfy all these stakeholders.
After twisting and torturing Jira's design tool quite a bit, I finally managed to get something convincing that met everyone's requirements.

NB: if a line has no arrow, it's bidirectional

On this flow there are 4+1 mandatory steps: Backlog, Todo, Doing, Done + Canceled. This last state is a bit apart, because it's a siding of little interest for our topic. The 4 main steps are all accessible via the “Toutes” transition, so it's quite possible to go from Backlog to Done, even if that's not the goal.
You can clearly see the breakdown of this flow into 3 distinct parts, and moving from one to another of these parts can only be done via our 4 indispensable steps. Within each section, you also notice that all steps are interconnected bidirectionally. Which means that from any status in a section you can move to any other status of the same type. We simulate, as much as possible, the “Toutes” transition, limiting this possibility to a section of the flow.
So to move from one type of status to another, you really have to go through one of our 4 essential steps … goal achieved.

• On the advantages side, we keep exactly those of the first idea and, because of the obligation to go through certain steps, we improve the reliability of the measurement and statistics.
• On the drawbacks side, we noticeably reduce the length of the transition menu in the ticket details; the number of accessible statuses is also a bit more limited.

So in the end, we're not really losing out and nobody really had anything to complain about. The production rollout was therefore accepted without too much trouble.

Usage

Visually, for everyday use, it looks like this:

No more limitations on moving tickets and, interesting detail, in the “Terminé” column you get the “Done” and “Canceled” statuses clearly identifiable. It's an interesting side effect of having made these two states accessible all the time: it's no longer possible to put tickets into the “Canceled” state by mistake.
On more classic flows, the “Canceled” state often has the “Toutes” transition, while “Done” was only accessible via the imposed path. So when you wanted to finish a ticket into a state it couldn't normally reach AND the “Canceled” state was mapped in that same column, the column was still accessible, but not for the state you assumed … and I've often recovered wrongly abandoned tickets.
With my solution, that's no longer possible.

Other notable changes

Priorities

A default Jira behavior that seems misleading to me is tickets being set to “Medium / Moyen” by default when they're created. How to distinguish newly created tickets — potentially with a priority not set yet — from those really at that level? So I had the priority system modified as follows, adding a “Not prioritized / Non priorisé” value as the default value.

In itself, nothing revolutionary, but a welcome little adjustment.

Support

I consider support tickets to be at the edge of the project, and they can have their own particular, better-suited workflow. Why do I say “edge of the project”? Because the people likely to create this type of ticket don't necessarily belong to the team, they don't necessarily have the habit of using this tool, and so you need to make their task as easy as possible by guiding them as much as possible. So in this case, out of the question to let them change the ticket's status too freely.

Feedback

After a few weeks of rollout on a pilot project, I didn't have many adjustments to make. Two statuses at the implementation level, automation on the transitions, but nothing more. Having promoted this flow a bit, other projects asked to switch to it … then it became the reference flow for the program, which strongly encouraged the other projects to switch.
A few more weeks went by and all the projects are happy with it. Lately, I also talked about it outside the program and some people seemed interested, which is encouraging for what's next. An interesting thing: seeing that the tool could really be adapted to make it more pleasant, projects came to ask me for other changes. For example, the far too numerous fields of dubious usefulness.

Conclusion

Once again, I don't know if what I've set up will fit your situation. In my case, I'm happy with it and the teams seem to be too, so why deprive yourself 😁.
Feel free to give me feedback if you've been inspired by the flows presented here; I'd be very happy to discuss it face to face 😄.