How to train a team to use Jira

The short answer

Train a team on Jira in four moves. First, agree and write down how your team uses Jira: what each column means, which work types you use, and when a ticket counts as done. Second, give people a place to practise where mistakes cost nothing. Third, teach five everyday skills in order: read a ticket, read the board, move your own work, create a ticket, and find things. Fourth, check in after two weeks and fix the setup, not just the people.

Plan to spend the most time on the first and fourth moves. Jira itself is not hard to click through. What confuses people is a board nobody explained and rules that live only in one person's head.

Here is a timeline you can adapt:

Step 1: Write down how your team uses Jira

Before you train anyone, decide what you are training them to do. Every Jira setup is different, so "learn Jira" means little until you answer these questions on one page:

• What does each column mean? On a board, each column groups one or more workflow statuses. Write one line per column: "In review: the work is done and a colleague is checking it." Then say who moves cards into and out of it.
• Which work types do you use? Atlassian's default work types for software spaces are Epic, Story, Task, Bug and Subtask; business spaces start with Task and Subtask. Say when to use each, with one example from your own work. The story, task or bug guide can help you write this part.
• What must every ticket have? For example: a summary that makes sense on its own, a priority, and for bugs, the steps to make it happen again.
• When is something done? If your team uses Scrum, this is your Definition of Done, which the Scrum Guide describes as "a formal description of the state of the Increment". If not, write a simple rule: "Done means it is live and the requester has been told."
• Who creates tickets? Only the team, or anyone who asks for work?

Keep this page short enough to read in five minutes, and link to it from the board's description or your team's wiki page. New joiners will read it on their first day, so write it for them.

While you write, open the board settings and check that every status sits in a column. In Jira Cloud, statuses that are not mapped to a column land in the Unmapped statuses panel, and work items in those statuses are hidden from both the board and the backlog. A trainee who cannot find a ticket will blame themselves, not the board. To check:

1. Next to your board's name in the sidebar, select More actions (•••), then Board settings.
2. Select Layout, then Columns.
3. Look at the Unmapped statuses panel. Drag any status that belongs on the board onto its column.

Step 2: Give people a safe place to practise

People learn Jira by clicking, and the first clicks are where they worry about breaking something. A new joiner who is afraid to drag a card on the live board will ask you instead, every time. Give them somewhere mistakes do not matter. You have three options:

• A practice space on your own site. Create a space called "Training" and let people create, move and delete tickets there. If you have permission to create team-managed spaces, you can set this up yourself: Atlassian describes them as set up and maintained by anyone on the team, while company-managed spaces need a Jira admin.
• A sandbox. On Premium and Enterprise plans, an organization admin can create a sandbox, a separate test site, from Atlassian Administration under Apps, then Sandboxes. Setup can take up to 30 minutes. This suits testing a new workflow before the team sees it.
• A practice board outside your company's Jira. Useful for complete beginners, because nothing they do shows up in your real data or anyone's notifications.

Whichever you choose, give each person a few concrete tasks rather than "have a play". For example: "Find PAY-142, read its latest comment, and move your own practice ticket to In progress with a comment saying what you did."

Step 3: Teach five everyday skills, in order

Day to day, people need five skills, and each one builds on the one before. Teach them in this order and have people do each one, not just watch:

1. Read a ticket. Key, summary, status, assignee, priority, description and comments. The key (PAY-142) is the one to point at in chat: it is unique and short, and it changes only if the ticket moves to another space or an admin changes the space key (old links still work).
2. Read the board. Which column is which, how to filter to one person, and what a flagged card means on your team.
3. Move your own work. Start a ticket, comment on it, hand it over. A comment such as "Fix is merged, Ana is testing it today" saves a round of "any update?" messages. The guide to changing status covers the board, the ticket and bulk changes.
4. Create a ticket. Pick the type, write a summary that stands alone, set an honest priority. Use your one-page rules from Step 1. The guide on writing a good Jira ticket has examples to share.
5. Find things. Search by key, then by words. Searching before creating also helps prevent duplicate tickets.

Two 45-minute sessions in the first week cover all five: skills 1 to 3 in the first, 4 and 5 in the second. End each session with a real task on your live board, such as Leila from finance moving her first real ticket to In progress while you watch.

If you want people to practise these skills before the session, or to catch up if they missed it, Agile Board Practice has six short lessons that follow the same order: read a ticket, read the board, move your work, create a ticket, find anything, and run a busy board near the end of a sprint. Each step on its practice board says whether the learner got it right and why.

Step 4: Add the skills each role needs

Once everyone has the basics, add what each role does on top of them. Keep these short sessions separate, so people only sit through what they use.

Scrum master or team lead

The Scrum Guide says the Scrum Master serves the team by "coaching the team members in self-management and cross-functionality". In Jira, that can mean owning the board: keeping columns matched to statuses (see Step 1), noticing tickets that sit too long in one column, and raising it at the retrospective. Teach them the board settings and how to read a board that has gone stale.

Product owner

The Scrum Guide makes the Product Owner "accountable for effective Product Backlog management". In Jira that means ordering the backlog so the top is what the team should pick up next, and writing tickets the team can act on. Show them how ranking works with the guide on sorting a backlog by priority, and how the backlog and the sprint differ with backlog vs sprint.

Testers and analysts

Teach linking ("blocks", "relates to", "duplicates") and how to write a bug someone else can reproduce. The guide on linking tickets covers the link types.

Managers and stakeholders

Some only need to read a ticket and the board, and to answer "where are we with this?" from the status and latest comment. That alone can replace a status-update meeting.

Step 5: Give everyone a starting filter

A new joiner's first question each morning is "what is mine?". Answer it once with a saved filter that everyone can use. Jira's advanced search uses the Jira Query Language (JQL), and this query finds work assigned to whoever runs it:

assignee = currentUser()

To run it in Jira Cloud, select Search in the top navigation (or press /), select View all work items, switch to JQL if basic search appears, and enter the query. Save it as a filter, then share it with the team:

1. In the sidebar, select Filters, then View all filters, and open the filter.
2. At the top of the page, choose Details.
3. In the Shares section, pick the group, space or space role and select Add, then Save.

You can only share with groups or roles you belong to. People can also subscribe to a saved filter to get its results by email: run the filter, select Details, then New subscriptions. Each email includes only the first 200 results, which is plenty for a personal list.

Step 6: Check in after two weeks and fix the setup

Two weeks of real use show you where the training or the setup is wrong. Spend 45 minutes with the team, or fold it into a retrospective, whose purpose in the Scrum Guide is "to plan ways to increase quality and effectiveness". Look at the board together and ask:

• Which tickets have not moved in a week, and why?
• Which column does nobody understand? Rename it or merge it.
• Which field does nobody fill in? Drop it from your rules, or explain why it matters.
• Were duplicate tickets created? That points back to the find skill in Step 3.

Update your one-page rules the same day. If one person keeps struggling, pair them with a colleague for a week rather than repeating the whole session.

Training several teams at once

When more than one team uses Jira, decide early which rules are shared and which each team owns. Company-managed spaces let a Jira admin standardise workflows across spaces: when the admin changes a shared scheme or screen, every company-managed space that uses it changes too. Team-managed spaces are self-contained, so each team controls its own process. Shared workflows make cross-team reports and handovers easier; separate ones let each team move faster. Either way, write one shared page with the common words (what Done means, which priorities exist) and let each team add its own column notes. The guide to boards vs spaces explains how the two fit together.

A Jira onboarding checklist for new joiners

Reuse this every time someone joins:

Let people practise before it counts

A plan only works if people actually try the steps. Agile Board Practice gives learners short lessons on a practice board, workplace tasks where a colleague's email asks for a status update, a bug report or a ticket to close, and timed puzzles on a busy board, such as finding what blocks a release. Nothing they click touches your real Jira, and every step comes with feedback, so your sessions can focus on your team's own rules.