The very first time I opened Jira, more than half a decade ago I thought everything was just… a ticket.
Then in the stand-up someone said,
“Put it under the Epic.”
A few minutes later:
“Actually, that belongs in a different Project.”
Then someone else asked,
“Is this a Story or a Task?”
At that point I realized Jira was a lot more than I had heard and it seemed complicated.
Come to think of it, it wasn’t complicated because it had too many features. It was complicated because I didn’t understand its mental model. Once that clicked, everything else started making sense.
Start with the business, not the ticket
People often learn Jira from the bottom up.
They learn how to create a Task.
Then a Story.
Maybe a Bug.
Eventually they discover Epics.
That’s backwards.
Jira is designed to model how organizations think about work.
Organizations don’t start with tasks.
They start with goals.
A business decides it wants to improve customer retention.
That goal becomes a collection of initiatives.
Those initiatives become features.
Those features become user stories.
Those stories become implementation work.
Jira simply mirrors that process.
The Project isn’t your feature
This is the first mistake almost everyone makes.
A Project is not a feature.
It’s a workspace.
Think of it as the folder where a team lives.
If your company builds an e-commerce application, you might have a project called:
E-Commerce Platform
Inside that project lives everything.
Features.
Bugs.
Stories.
Tasks.
Releases.
Documentation.
The project answers one question:
Where does this work belong?
Not:
What are we building?
Epics are features people recognize
If I asked your customers what your application does, they’d never say:
“It has Story #384.”
They’d say:
- Checkout
- User Profiles
- Search
- Notifications
Those are Epics.
They’re large chunks of functionality that users actually experience.
They aren’t completed in a day.
Sometimes not even in a sprint.
Instead, they’re divided into smaller pieces.
Stories are promises to users
This is where Agile starts to feel human.
Instead of saying:
Build password reset endpoint.
A story says:
As a user, I want to reset my password so I can regain access to my account.
The technical work still happens.
But everyone understands why it exists.
A good story delivers value on its own.
When several stories come together, they complete an Epic.
Tasks aren’t Stories
This confused me for a long time.
A Story exists because a user needs something.
A Task exists because the team needs something.
Nobody logs into your application hoping you’ve upgraded PostgreSQL.
But your engineers certainly care.
Infrastructure work.
Documentation.
Server configuration.
Deployment pipelines.
These are Tasks.
They’re important.
They’re just not user-facing.
Bugs are work too
One thing I appreciate about Jira is that it doesn’t treat bugs as something separate.
A bug is simply another type of work.
Maybe checkout crashes in Safari.
Maybe the login button stops responding.
Maybe an API suddenly returns HTTP 500.
They’re all tracked, prioritized, estimated, and resolved like everything else.
Because fixing broken software is still delivering value.
Spikes are permission to not know
One of my favorite issue types is the Spike.
Software teams often pretend they know the answer before they start.
Spikes acknowledge the opposite.
Sometimes the right answer is:
“We don’t know yet.”
Maybe you’re evaluating payment providers.
Maybe you’re comparing authentication services.
Maybe you’re testing whether an architecture will scale.
The goal isn’t shipping code.
The goal is reducing uncertainty.
That’s valuable work too.
Sub-tasks are where the actual implementation happens
By the time developers start coding, they’re often working on Sub-tasks.
A Story like:
Create Login Page
might become:
- Build the UI
- Implement the API
- Write tests
- Review the code
These aren’t new features.
They’re simply pieces of the same Story.
Sub-tasks keep implementation organized without cluttering the backlog.
And then there’s the word “Issue”
This might be Jira’s most confusing piece of terminology.
Everything is an Issue.
Stories are Issues.
Tasks are Issues.
Bugs are Issues.
Epics are Issues.
“Issue” doesn’t describe the work.
It simply means:
Jira is tracking this thing.
Once I stopped trying to give “Issue” a special meaning, it stopped being confusing.
The hierarchy
When you put everything together, the model is surprisingly simple.
Project
│
├── Initiative (optional)
│
├── Epic
│
├── Story / Task / Bug / Spike
│
└── Sub-task
The higher you go, the more you’re talking about business.
The lower you go, the more you’re talking about implementation.
That’s really all the hierarchy is doing.
One mental model changed everything
Today, I don’t think of Jira as a ticketing system.
I think of it as a map.
Projects tell me where work lives.
Epics tell me what we’re building.
Stories tell me why we’re building it.
Tasks tell me what needs to be done.
Sub-tasks tell me how we’ll get there.
Once you start looking at Jira through that lens, the hierarchy stops feeling like bureaucracy.
It starts feeling like a shared language between product managers, developers, designers, QA engineers, and stakeholders.
And that’s probably the real purpose of Jira, not tracking work, but helping everyone talk about the same work at different levels of detail.
