When I first used Jira… I thought I was using it wrong
When I started working with Jira in 2014, on Jira Server 6, I believed I was learning a tool designed for software teams.
That’s what Jira was supposed to be.
But my very first implementation told a completely different story.
My first Jira project wasn’t for developers
In 2014, I implemented my very first process on Jira.
It wasn’t a software project.
It was a leave request workflow.
And here’s the interesting part:
That process is still running today.
More than 10 years later.
With almost no major changes.
A simple workflow… that worked for years
The process was straightforward:
- An employee creates a leave request (issue type: Leave Request)
- They provide:
- start date
- end date
- address during leave
- optional description
- The request is assigned to the manager
- The manager approves or rejects it
- If rejected → a reason is mandatory
- If approved:
- a leave document is generated and attached
- the employee receives it
- Before the leave starts:
- the employee can modify the dates
- via a sub-workflow with validation
What struck me back then was this:
Jira was not just tracking work.
It was structuring a real-life business process.
And it worked.
For years.
That’s when I realized: Jira has two faces
Over time, I started seeing Jira differently.
Jira is like a coin:
- Heads → Dev Tool
- Tails → Workflow Engine
And most organizations… only use one side.
Heads: Jira as a Dev Tool
On one side, Jira became the backbone of software delivery.
Integrated with tools like:
- Git
- Jenkins
- test management tools like TestRail
- design tools like Figma
It enables a fully connected workflow:
- design → development → testing → deployment
Everything is centralized in Jira.
Everything is traceable.
Everything is aligned.
A real Dev workflow
In one of my projects, Jira was connected to:
- Figma (design)
- Git (code)
- Jenkins (CI/CD)
- TestRail (QA)
This allowed us to:
- automate the dev-to-QA loop
- centralize information
- reduce friction between teams
Jira here is a delivery engine.
Tails: Jira as a Workflow Engine
But the other side is just as powerful.
Jira can model almost any business process.
Let me give you another real example.
Insurance use case: claims management
In an insurance context, we implemented a claims declaration process using Jira.
Here’s how it worked:
- A claim is created in Jira
- A repair service is automatically assigned
- The client is contacted to schedule an appointment
- Once the repair is completed:
- the billing process is triggered
Same tool.
Completely different purpose.
Jira becomes:
- a coordination engine
- a decision workflow
- a business process orchestrator
The reality I’ve observed
Across many organizations, I’ve noticed a recurring pattern:
Jira is used either as a Dev tool
or as a workflow tool
But rarely both.
The consequence?
- IT teams work in Jira
- Business teams use other tools
Or the opposite.
Jira is deployed…
but not fully adopted.
Jira didn’t change overnight — it evolved
Over the years, Jira expanded:
- from Dev tool
- to extensible platform
- to collaboration hub
- to service management solution
With Jira Service Management, the workflow side became official.
And now… a third dimension
Today, we are entering a new phase:
Collaboration + Intelligence
With tools like:
- Confluence
- Jira Service Management
- Rovo
Jira is no longer just tracking work.
It is helping us understand work.
From coin to platform
For years, Jira was a coin:
Today, it’s something else.
A work platform
A platform that connects:
- people
- processes
- knowledge
- intelligence
Final question
So here’s the real question:
How do YOU use Jira in your organization?
- Only for development?
- Only for workflows?
- Or both?
I’d love to hear your experience:
Have you ever used Jira beyond development?
What worked… and what didn’t?
