📝 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!