Jira Crash Course (2026): Scrum, Kanban, or Something Simpler?

Here's the question almost nobody asks before setting up Jira, and it causes more mess than any other decision: which of the three ways of using Jira does your team actually need?

(One naming note before we start: Atlassian now calls projects "Spaces." Same thing — I'll use "Space" throughout, but don't be surprised if older screenshots, videos, or your own instance still say "project.")

Because there are three, and they are not equal:

• Scrum — for teams that genuinely run sprints, plannings, and retrospectives
• Kanban — for teams with continuous flow of work (most teams, honestly)
• Work Management ("Business" Space / projects) — for everyone who just needs clean, simple task tracking without any agile ceremony at all

After 14 years of implementing Jira for organisations like the BBC, NHS and Lloyds Bank, here's my honest pattern: most teams that ask me for Scrum actually need Kanban. And a surprising number of teams that ask for Kanban actually need a simple Work Management Space and a tidy board. Start simpler than you think — you can always add ceremony later.

This guide helps you make that decision properly, then set up your first Space the right way — using mostly out-of-the-box settings, which are far better than people give them credit for.

The three ways to use Jira (and which one is you)

Work Management — "we just need to track our work"

This is you if: you're a marketing, HR, operations, finance, or any non-development team — or a small business that just wants tasks, owners, and due dates without learning a methodology.

Work Management Space are genuinely well designed: clean, clear, straightforward. I've had clients who spent months insisting "Jira is too complicated" — and once I showed them a Work Management Space, they were working in it the same day. It gives you list views, calendars, simple boards — the Trello experience, but inside the ecosystem your company probably already pays for.

(The full Work Management crash course is coming — subscribe below and it'll land in your inbox.)

Kanban — the default answer for most teams

This is you if: work arrives continuously — support items, small changes, maintenance, development without fixed sprints — and you want to see it flow across a board.

Kanban is my default recommendation whenever a team is unsure. It has everything most teams need (including a backlog, if you enable it — a hidden gem most people miss) without the ceremony Scrum demands. If you're hesitating between Kanban and Scrum, that hesitation itself is the answer: go Kanban.

(Full Kanban crash course coming — it's the next article in this series.)

Scrum — for teams that actually do Scrum

This is you if: your team genuinely plans in sprints, holds sprint planning and retrospectives, and wants velocity metrics. Not "we'd like to be agile someday" — actually does these things, on a calendar.

Scrum in Jira is excellent when it matches reality and pure overhead when it doesn't. An abandoned sprint board with 40 overdue items is the most common monument to optimism I see in client instances.

(Scrum crash course coming too — subscriber list gets it first.)

What actually is Jira in 2026?

Jira is the number one project management tool on the market, and it's long outgrown its "bug tracker for developers" reputation. It's a full work ecosystem: Scrum, Kanban, and simple task management in one product, connected to Confluence for documentation and Jira Service Management for service desks.

The ecosystem is the underrated part. Teams buy a standalone tool, and six months later someone says "it would be nice to have documentation" — and now they're juggling Google Docs on the side. In the Atlassian world, that's often literally one click: activate Confluence, done. And here's a licensing detail most people don't know: you don't have to match plan tiers across products. I have clients running Jira Premium with free Confluence, because only six people need the documentation. Mix and match; nobody will stop you.

One honest warning about 2026 specifically: Atlassian is mid-way through renaming things. Issues are becoming "work items" (everyone still calls them tickets), projects are becoming "spaces", and the Summary field is now "Title". As an admin I find the renaming annoying and slightly confusing for existing users — but for brand-new users the new terminology is genuinely clearer. If your screen doesn't match a tutorial word-for-word, this is why.

"But everyone on Reddit hates Jira"

Some people do, and I've made a habit of asking them why. The answers are almost always one of two things.

"It's not logical." When I dig in, this usually comes from people who spent years in Monday, Asana, or Azure DevOps and expect Jira to work identically. It doesn't — and having implemented and compared these tools, I'd argue Jira's core logic is actually the cleanest of the lot: a crystal-clear hierarchy (epic → story/task → sub-task), every work item belonging to exactly one project, and every item getting a short unique ID you can search, link, and reference anywhere. Some competitors don't even give you that. The frustration is the cost of switching, not a defect in the tool — I lose my mind the same way in reverse whenever I have to work in DevOps.

"It's expensive." It's not cheap — but in real client comparisons at 50+ users, Atlassian comes out cheaper than Monday, Asana, or comparable tools more often than not. And there's a fairness point worth crediting: some competitors run four-plus pricing tiers and show you features that turn out to be locked behind a higher plan than the one you're on — I've hit this personally during client assessments, mid-demo. Atlassian shows you Premium features clearly labelled as Premium, with a free 30-day trial to test them. That's the honest version of upselling.

Is Jira perfect? No — it's grown a bit bloated, and I've listed my complaints above. But most of the hate is muscle memory from other tools.

Pricing: what you actually need (July 2026)

As of writing — always check Atlassian's pricing page, these numbers move — Jira Cloud runs three plans: Free, Standard ($9.05/user/month), and Premium ($18.30/user/month), with per-user prices dropping at higher user counts. Rovo, Atlassian's AI, is now bundled into Standard and Premium.

Free plan — honestly, skip it for production. This is where I've changed my tune from a few years ago. Ten users, no ability to set permissions on projects (everyone sees everything — a real problem inside any actual organisation), and enough missing functionality that it can actively mislead you about what Jira can do. It's fine for a personal sandbox. It's not fine for running a team.

Standard is the sensible production entry point: unlimited-ish users, proper permissions, Rovo included.

Premium is "full Jira." The headline feature is Plans (advanced roadmaps — cross-project visibility, capacity, dependencies), plus sandbox environments and much higher automation limits. My honest advice: if you'll use Plans, Premium justifies itself immediately. If you won't, Standard plus a third-party app where needed is a perfectly respectable setup — and you can trial Premium free for 30 days on your production site to find out (Atlassian will often extend the trial if you ask).

What about Enterprise?

I get asked about this more than you'd expect, and the honest answer is: Atlassian doesn't publish it, and that's by design. There's no self-serve price list — Enterprise is sold through account managers or partners, and the number you're quoted depends on your organisation's size and region.

The one detail worth knowing before that conversation: Enterprise has a minimum seat commitment, and it isn't the same everywhere. In the UK, US and most of Europe, expect a floor somewhere around 500 users; some smaller markets have a lower minimum. If your organisation is well under that number, you're probably not the customer Atlassian is pricing Enterprise for — Premium is almost certainly your ceiling, and that's not a bad ceiling.

What you get for it: centralised administration across multiple products/sites, more advanced security and data residency controls, and — the feature clients usually ask about by name — enterprise-grade templates and cross-org roadmap views. If your business genuinely operates at that scale, it's worth the conversation. If you're weighing it "just in case," the honest answer is: talk to Atlassian directly, and don't let the mystery pricing make it feel more essential than it is.

The elephant in the room: team-managed vs company-managed

This is the decision that quietly determines whether your Jira stays tidy or descends into chaos, and most teams make it by accident — because by default, anyone in your Jira can create a team-managed project. No admin rights needed. I've watched organisations discover duplicate projects they didn't know existed, each configured differently, because the default let anyone click "create."

The short version: company-managed projects share configuration — workflows, custom fields, screens — across the site, and only admins can create them. team-managed projects are closed little worlds each team configures itself. I used to hate team-managed projects; I've softened — for a genuinely independent team, the isolation is a feature. But without governance, team-managed sprawl means five projects with five different workflows and reporting that can never be trusted.

Two things I tell every client:

First: lock down project creation. Decide deliberately who can create what. This single admin setting prevents more chaos than any other.

Second — and almost nobody warns you about this: there is no one-click conversion between the two types. Moving from team-managed to company-managed means migrating work items, remapping custom fields, and reconciling workflows — doable, I do it regularly, but it's a proper job, not a button. And the traffic is almost entirely one-way: of every ten of these migrations I've done, nine-plus were teams escaping from team-managed to company-managed. Pick deliberately the first time.

Setting up your first Space (project) the right way

Here's my strongest, least-fashionable opinion: the out-of-the-box setup is genuinely good. You can have a Kanban project running on production in a few clicks, and with an hour or two of tweaks it's more than decent — the default templates have gotten quietly excellent. The 300-custom-field nightmares I get called into were all built by people who thought defaults weren't enough.

Columns: start with something like Backlog → To Do → In Progress → In Review → Blocked → Done — and honestly, fewer is fine. I know people resist a "Blocked" column, but I love it: you can hang automations off it ("blocked for 3 days → notify the lead"). What you shouldn't do is twelve columns; I've watched a client's productivity jump just from cutting their board back to three.

Work item types: the defaults (epic, story, task, bug) are fine for almost everyone. Think of the type as a tag with rules, not a sub-project — I've seen teams invent exotic custom types and confuse everyone. Epics group stories; if you eventually outgrow epics, that's what initiatives are for.

Custom fields: before creating one, check whether it already exists — most of the fields people want (dates, reviewers, categories) are already in the system waiting to be added to a screen. Duplicated custom fields are the slow poison of Jira instances.

Workflow: for a new project, your board basically is your workflow — the simplified workflow mirrors your columns, and that's exactly as complicated as it should be. Resist adding statuses until reality forces you. (Full workflow guide here.)

Automation: the right amount is more than zero and less than everything. I have clients using not a single automation rule — they're leaving free productivity on the table ("in Blocked for 3 days → send a Slack/Teams reminder" takes two minutes to build). I also have a client who automated everything, something broke, and nobody could work out what. Set up the structure first, then add automations one real need at a time.

"Jira only allows one assignee" — the complaint, answered

I get this question constantly from teams arriving off other tools: "What if three people are working on the same item?" My first answer is a question — how, exactly? — because usually it means the item is too big and should be split. But when it's real, Jira gives you layers before you need to build anything:

1. Assignee = the one person accountable (the lead on that item)
2. Teams — Atlassian is pushing these hard, they're free, and they work like a taggable group
3. Watchers — out of the box, everyone who needs visibility
4. And only if all that genuinely isn't enough: a custom multi-user field ("Additional assignees")

Start at the top of that list. Every layer you add below it is a little more chaos to govern.

Common mistakes (the ones I actually get paid to fix)

Over-complication — too many statuses, duplicated custom fields, exotic work item types, five "additional people" fields on every ticket. Everything drifts toward complexity; your job is to drift it back.

Too many columns — start with a handful, add only when a real bottleneck demands it.

Automation extremes — zero rules (wasted potential) or automating everything (unmaintainable). The middle path, added gradually, wins.

No training — Jira is only as good as your team's understanding of it. Tools don't create adoption; people showing people does. Training gaps are the root cause behind half the other problems on this list.

FAQ

Is the free plan enough for a small business? For a sandbox, yes. For production, I don't recommend it — 10 users, no project permissions (everyone sees everything), and enough missing features to mislead you. Start on Standard, or trial Premium free for 30 days.

Can I convert a team-managed project to company-managed later? Not with a button. It's a migration — moving work items, remapping fields — and it's a proper job. Choose deliberately upfront; when in doubt, company-managed.

Is Jira only for software teams? Not anymore. Work Management projects are built exactly for marketing, HR, ops and finance teams — and they're one of the best parts of modern Jira.

Jira or Trello? Trello still exists and Atlassian still sells it, but a Work Management project gives you nearly everything Trello does, inside the same ecosystem as everything else. For a new setup I struggle to recommend Trello over it.

Where to go next

Pick your path from the three at the top — the dedicated Kanban and Scrum crash courses are next in this series, and subscribers get them first (signup card below).