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 ;)