WEEK 1 - “The Day Jira Fought Back”

[#1]

SPECIAL SERIES ANNOUNCEMENT

I’m starting this weekly series to share what life really looks like behind the scenes as a Jira Admin.
Not the polished version - the actual reality: messy configurations, late-night escalations, broken SLAs, confused teams, and the constant battle to keep Jira, JSM, and Confluence working together.

Welcome to:

“Inside the Atlassian Recovery Project - A Weekly Thriller”

WEEK 1 - “The Day Jira Fought Back”

Episode Summary

Our story begins with a Jira instance so messy that it felt like a living creature.
This week, we uncover the disaster, the panic, the shocking discoveries - and the twist that pushes us straight into Week 2

1. A Normal Day… Until It Wasn’t

It was supposed to be a regular Tuesday.

I was sipping my coffee when a senior engineering manager, barged into my workspace - laptop in hand, breathing like he just ran a marathon.

“Jira is broken,” he said.
“And this time… it’s breaking us.”

He wasn’t exaggerating.

A single sprint had turned into a full-blown crisis.

• Tickets stuck in wrong statuses
• Three “In Progress” statuses in the same project
• Story points gone missing
• Issues vanishing from boards
• Burndown chart looking like an ECG machine
• Developers tagging me every hour

Something was terribly wrong.

And I had no idea just how deep the rabbit hole went.

2. When Tools Start Controlling Teams

The more we dug, the more chaos we found:

• 630+ workflows
• 1100+ custom fields
• 300+ screens
• 6 versions of “Bug”
• 9 different definitions of “Done”
• SLAs violated due to inconsistent statuses
• PMO unable to trust reports
• Leadership assuming the teams were slow

But the truth?

Teams weren’t slow.
Jira was overloaded.
And nobody had taken ownership in years.

This was no longer a tool.
This was a jungle.

3. Investigation Day - Operation Detox

We launched something we later named:

“Operation Detox: The Great Jira Audit.”

For 5 straight days, we went all in:

• Interviewed 30+ users
• Compared workflows
• Dissected screens
• Tracked who created which field (nobody remembered)
• Found duplicated fields like:
  • Severity
  • Severity_1
  • Severity (New)
  • Customer Severity
  • Sev Customer

It was like finding multiple versions of the same movie… none ending well.

A frustrated developer whispered:

“Updating Jira feels harder than writing the code.”

That one sentence changed everything.

4. The Plan That Would Change Everything

We assembled a core group - the Jira Architecture Council.

After long debates, raised eyebrows, and a few sarcastic comments, we agreed on a bold, risky plan:

• Reduce 630 workflows → 20 master workflows
• Reduce 1100 fields → 600 meaningful fields
• Reduce 300 screens → 20 enterprise screens
• Introduce global project templates
• Enforce governance to stop future chaos
• Migrate teams in controlled batches

One admin joked:

“So we’re basically performing open-heart surgery on Jira while it’s running.”

Yes.
Exactly that.

5. The Breakthrough Moment

After weeks of cleanup, consolidation, and migration…

Jira finally breathed.

• Sprint velocity stabilized
• Burndown charts made sense
• Developers updated tickets willingly
• Reports reflected reality
• Newly created projects worked right out of the box

The senior manager walked in again - but with a smile this time.

“This feels like a whole new Jira,” he said.
“Teams are actually moving faster.”

The nightmare was ending.

Or so we thought.

6. Cliffhanger - Something Started Breaking… Elsewhere

Just when we were celebrating, my phone buzzed at 11:47 PM.

A message from the JSM Support Lead:

“URGENT. Something is wrong.
After your Jira fixes, all our JSM SLAs just went red.
Every critical incident is stuck.
Priority mismatches.
We think the workflow cleanup triggered something… downstream.”

Attached was a screenshot full of broken SLAs, escalations, and red timers.

While fixing Jira…
we had awakened another beast.

And this one was angrier.

TO BE CONTINUED…

Next episode drops next week.

WEEK 2 - “The JSM Meltdown: When SLAs Started Bleeding Red”

[Manish Nadar]

Great initiative. Looking forward for next episode 😃

[s_gridnevskii]

I never understood why people have severity in addition to priority. If customer is in big trouble then save him as soon as possible - use priority Highest. In one company where I worked as a head of support I even had a red flag - when production failed I raised this flag on my monitor and everyone from QA to development had to stop their activities and resolve the issue.

[s_gridnevskii]

For the SLA - obviously you did not check them before applying 20 master workflows. I guess you also put arbitrary statuses when applying general workflows to issues and you will have more problems in series 3. I always take a project lead with me when I apply a general workflow and we sit together and set proper statuses so that everyone is happy.

Additionally there can be hundreds of conditions and post functions in 600 workflows and of course they are not there in 20 generic. Developers will not notice the change until they run across problems in e.g. deployment. 

I strongly disagree on operations on open heart. Planning, small improvements, test environment. Otherwise you quickly get fired.

[Akhand Pratap Singh]

HI @s_gridnevskii

Thank you for sharing this - and I completely understand where you’re coming from.
Just to clarify: this series is written as a narrative, not a literal “here’s exactly how one should push changes in production.” In real-life environments, I would never deploy 20 master workflows without mapping SLAs, pausing automations, validating transitions, and reviewing everything with project leads. There’s always a test environment, migration planning, and proper approvals. No disagreement there.

The intention of the story is to reflect the reality many Jira admins face - walking into an inherited instance where years of inconsistent changes, missing documentation, and conflicting workflows create invisible dependencies that even careful planning can’t fully uncover immediately.

Now that being said, I have always been a strong believer in standardized processes, because:

1. Everyone is aligned on what to do and when to do it.

2. You actually have documentation that reflects your real process.

When every project manager follows a different model, it creates confusion for developers, QAs, and agents working across multiple projects. Consistency reduces mental load and increases efficiency across teams.

And yes - sometimes you genuinely need to perform those hard cleanups, suffer for a week, and come out with a cleaner, predictable system… rather than keeping the mess intact and fighting the same fires forever.

The upcoming episodes (especially Week 3 and Week 4) dive deeper into the hidden conditions, post-functions, and historic dependencies that caused the ripple effects. This is part of the unfolding story rather than a recommendation to “change everything blindly.”

Really appreciate your view - discussions like this make the series even more valuable for the community.

Cheers, 

Akhand

[Logi Helgu]

Fun post <3 Love to hear real stories here and with a nicely setup...looking forward to the sequal ;)

[Carolyn White]

Dang! Have you been reading my emails over the last 2 years? For two years I've been telling the powers that be, "Hey, there's an iceberg up ahead and we are headed straight for it!" You describe our Jira instance to the T (as in Titanic, keeping on theme.) I am jumping up and down in glee that someone other than me is saying the exact same thing! Ahhh, the sweet smell of validation.

1. Can we PLEASE have guidelines, standards, laws, rules?  I don't care what word is used, just something that lets people know their behaviors and actions are bringing us closer to the iceberg.

2. Can we PLEASE have documentation so that people know what they are even supposed to be doing - or not doing?

3. Can we PLEASE reign in the confusion of Jira roles and permissions and stop assigning things willy-nilly?

@s_gridnevskii - It is fantastic that you have been able to create and manage the chaos that we are referring to. I would push back a little on the aggressive tone implying that @Akhand Pratap Singh singlehandedly and with intent created the hot mess that Jira has become for him. Frequently, the person who sees the iceberg up ahead or has to deal with the aftermath is not the same person making the decisions. I applaud the decision to take a hard look at the as-is and reduce it down to a sustainable level.

To further play this out, I have been encouraging the formation of a process governance team so when someone wants to change something, there is testing to determine what impacts there may be. I use the Power BI connector to analyze the raw data, not just what Jira says and when a team changes something without my knowledge, it adds unnecessary complexity and re-work.

HUGE shoutout for saying this out loud, @Akhand Pratap Singh 

[Carolyn White]

@s_gridnevskii  - The difference between Severity and Priority is a common question and, in some cases, both are helpful. Severity describes the depth of the problem (intensity) and Priority describes the width (how many people are impacted.) There could be a low priority bug that mildly impacts most of the organization. It doesn't disrupt their day, but it is a nuisance that they have to deal with until resolved. On the other hand, of course, there could be a bug that disrupts only the CEO's day which becomes an "all hands on deck" scenario.

Bottom line, there can be very valid reasons for some companies to use both.

[Anthony Asuncion]

This was a great read, but sorry to hear of the challenges.  A good reminder to keep this in perspective. Thank you for sharing!

[s_gridnevskii]

@Carolyn White I guess Severity is important only for team lead. Assignee (the one who fixes the problem) should not care about severity at all. He sorts his tasks by priority and fixes most important ones.

Perhaps Severity should be present on issue creation screen, especially on service desk portal. After creation automation tool (or ai assistant or team lead) assesses severity and other fields, maybe workload of an employee, then assigns the issue and sets priority. If it is a developer then priority is not of any use as well since all issues in sprint should be resolved until end of sprint and order is not important.

[Michael Wohlgemuth]

Great read, this. Well written and every admin can tell a somewhat similar story, im sure.