📝 Jira: Heads or Tails?

[Amina CHAYEB]

 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:

• Dev Tool
• Workflow Engine

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?

[Stephen_Lugton]

One of the teams I work with is cross functional and includes members from our engineering, marketing and digital separtments.

For this team we have one shared project with 2 boards that we use daily for stand ups, reviews, etc. (we actually have 5 boards in this project space, but the other 3 are used less e.g. 1 board only shows work items with a 'For-refinement' label that we use in refinement sessions).

Our daily stand ups include time for the data engineers where we use a scrum board and use Jira as a Dev Tool, we then switch to the other board for the marketing / digital part of the stand up; this is a Kanban board that we use as a workflow tracker.

So I guess you could say we use Jira as a combined work platform..

We have other teams that use Jira solely as a Dev Tool - noticeably DevOps and Data Engineering, some that use it for regulatory and audit work - e.g. our Compliance and Data Governance teams, while other teams use it for ideation - e.g. Product (with both JPD and Jira).

My monthly reporting to the board comes directly from Goals, JPD, JSM, and Jira.  Although I do have to do screen grabs to get what I want in the format I want from Goals!

[Ingo Wenke]

Great to read about usage beyond Software-Dev.

I've introduced Jira in a real world manufacturing business. Assembling cargo bikes. We implemented two processes with common touchpoint.

1. B2B2C Process within JSM for our full Business and Customer communication - from interesting to order, production updates and shipping.

2. Production and Logistics Workflow, from Order to schedule to preproduction and production, QA and shipping, inclusive. labeling and shipping docs.

After confirming the order, the B2B (sales partner) and B2C Consumer Communication was fully triggered by the production flow, delivered status updates to the flow in JSM. 

All processes, steps and status were tracked on dashboard and we have real time updates end-to-end. Our engineers (mechanics) in production gave real time updates by confirming assembly steps or scanning serial numbers or storage IDs.

This was my outmost non-dev experience with Jira and Jira Service Management.