Jira Agile Boards: Why and How to Create Swimlanes

‘Swimlanes’ is another of those words that the tech world has co-opted to mean something new and fancy. But there’s always rhyme and reason to which words get reapportioned. ‘Sprints’ are about working in short, sharp bursts, not worlds away from running in short, sharp bursts. Likewise, swimlanes in Jira are about making your Jira board look like a swimming pool. Well, sort of.

This article explains what Jira swimlanes are, what they’re used for, and how to create them. And we’ll use the Scrum board of the Custom Charts for Jira marketing team as an example.

What are swimlanes in Jira?

Jira agile boards are already broken down into vertical columns for the different statuses of your workflow. For example, the Custom Charts marketing team’s Scrum board is divided into “To Do”, “In Progress”, “In Review” and “Done” columns.

Swimlanes are an optional feature that divide the board up further, this time into horizontal rows that correspond to a chosen category, e.g. assignee or epic. Like the lanes of a swimming pool. It’s just a way of further breaking up all the issues in your sprint or project, to make your board more manageable.

Our marketing team’s Jira board is divided up into assignee swimlanes, as you can see below. So, all my issues appear in one row, all our graphic designer’s in another, all our marketing manager’s in another, and so on. This is because it’s useful to both the team, and each team member, to see the workload of each person.

To be honest, even though they’re optional, I think swimlanes are a necessity of Jira life. Our marketing manager, Teodora, and I were just playing around with our board, and we turned the assignee swimlanes off. Suddenly all the issues were sprawled across the board in no particular order and each status column looked like a bottomless pit of work. Made both our eyes water.

What Jira swimlane options are there?

Jira comes with six distinct options for swimlanes, each with differing purposes and uses.

Base Jira Swimlanes on Queries, Stories, Assignees, Epics, or Jira Projects


Well, as mentioned above, we wouldn’t even consider having no swimlanes because it would make our board look a mess. If you’re just getting to grips with your Jira Scrum or Kanban board, and you only have a few issues, then you can probably go without, at least till your workload grows. But for larger teams with lots of issues in Jira, swimlanes are a must.


The Scrum boards for both the marketing team and the Custom Charts development team are divided up by assignee. Any unassigned issues sit above or below the swimlanes, whatever you prefer.

A person-by-person view of what work is assigned to who is useful for a quick view of the workload by any team member, and especially the team leader. You’re able to see potential bottlenecks, how much a project is relying on any one individual, and whether all team members are keeping up with their tickets.


Epics are larger bodies of work which comprise multiple tasks and often span several sprints. Organizing your swimlanes according to epic is a great way of giving the team a big picture overview. Team members and their managers can see at a glance how many issues are in different epics, and how those tasks are progressing.


Stories are also larger bodies of work, but they’re smaller than epics. They’re called stories, short for “user stories”, because they’re supposed to describe a task from an end user perspective, e.g. “I want to be able to divide up my agile board”. This might have been the story that led Atlassian to create swimlanes for Jira. A team will then create tasks to deliver that story. Dividing up your tasks into story swimlanes is similar to dividing them up by epic; you get to see how many tasks are in each story, and how they’re progressing.

If you’re a marketing team, you’re probably not using stories, because you’re not delivering directly to end users. You’re more likely to be using epics to encompass larger bodies of work. Product and development teams more typically use stories because they’re creating features as a response to requests from end users.


If you have tasks on your Jira board that span multiple projects (our marketing team’s issues are only in one project, the Marketing Project), then sorting by project name could be useful. You’ll get a view of the status and dependencies of each project at a glance, which is great for any teams juggling several projects.


You can create custom swimlanes using Jira Query Language (JQL) search criteria. This is actually pretty easy even if you don’t really understand JQL and try to avoid using it at all costs.

A popular query-based swimlane choice is to sort issues by priority. To do this, you simply:

  1. Add a new swimlane
  2. Type, for example, “priority=low” into the query field
  3. Name the swimlane something like “Low Priority Issues” and enter a brief description, if you fancy.
  4. Add further swimlanes with, for example, “priority=medium”, “priority=high” and “priority=highest” queries.
  5. Issues that don’t fit any search criteria will appear in the default swimlane “Everything Else”.

While our marketing team has chosen to use assignee swimlanes for our board, we could as an alternative have sorted our tasks into swimlanes based on “Components”. We use components to organize our issues into groups, such as “Blog”, “Event”, “Social Media”, “Website” etc.

So, we could use “component=blog” as a JQL query, and this would give us a swimlane comprising just our blog-related tasks. Every other task would be listed above or below, unless we made other swimlanes to divide these up as well. For example, we make videos too, so we could have a swimlane for our video-related tasks using the JQL “component=video”.

Jira quick filters as an alternative to swimlanes

When choosing swimlanes, you might be conflicted as to the options that are best for your team. But you don’t need to fret too much. Because Jira quick filters offer a very similar solution for organizing your board.

Once quick filters have been added by a Jira admin or board admin, they become powerful private tools for individual users. Any user can apply a filter to their own board view without affecting anyone else’s board view. Also, swimlanes keep all the issues on the board, whereas quick filters only display those that meet the filter criteria. Users can flip between filters or click on more than one to refine their search further.

Screenshot showing quick filters on a Jira board

In addition to assignee swimlanes, our marketing team has several quick filters in the event that we want to break down the issues differently. So we have a “Blogs” filter and a “Videos” filter in case we want to only see those issues, and these are based on “Components”. This was better for us than having components-based swimlanes because we have quite a lot of components. Components swimlanes would have meant ending up with too many rows and sometimes only one or two tickets per row. And if we only had a few components on there, rather than all of them, the other issues would just get lumped into the “Everything Else” swimlane.

Quick filters avoids these problems by letting individual users choose what they want their board to look like as a given time.

Even if you don’t want quick filters, Jira gives you an assignee one anyway

Even if you don’t add quick filters to your board, you’ll find that your board already has a special default filter already added: the assignee avatar buttons that appear next to the search bar.

Screenshot of assignee buttons on a Jira board

This means that on every board, regardless of its swimlanes or quick filters, you have the option of clicking on a particular assignee and seeing only their issues. To be honest, I tend to use this filter all the time. I glance at the whole board from time to time to see what issues others in my team are working on. Otherwise, I click on my avatar and filter the board down to only my issues, as these are the ones most relevant to me.

Weirdly, there is also an optional “Only My Issues” quick filter. But this is totally unnecessary because of the avatar buttons and I have literally never used it in my life (and it’s one of the default ones! Atlassian, stop being weird).

How to configure swimlanes and quick filters

Only Jira admins or board admins can configure a board’s swimlanes or add quick filters to it (apart from the assignee avatar buttons which are always there).

To add swimlanes to a Jira board, navigate to that board and do the following:

  1. Click on Board > Configure
  2. Click on Swimlanes in the side bar
  3. Choose from the standard options (as described above) or select Queries to create custom swimlanes

To add quick filters, go to board settings and select Quick Filters in the sidebar. There will be two default options: “Only My Issues” and “Recently Updated”. Which isn’t many, and “Only My Issues” is completely pointless because of the assignee avatar buttons. So you’ll want to determine which filters will be most helpful to your team and create them with JQL.

Here are the custom ones we have on our Jira board, with the JQL we used to make them:

  • Due this month: due >= startOfMonth() and due <= endOfMonth()
  • Unassigned: assignee in (EMPTY)
  • Videos: component=video
  • Blogs: component=blog
  • Events: component=event
  • Whitepapers: component=whitepaper

I’m going to speak to our marketing manager, Teodora, when she’s back off her (very well-earned) holidays about whether she thinks we need the “Unassigned” quick filter. Particularly as we have assignee swimlanes, so any unassigned issues appear at the top of the board anyway. I might also share my opinion on the uselessness of the “Only My Issues” one!

Jira swimlanes and quick filters are a fantastic way of making your agile board organized, easy to use, and friendly to the eye and brain. As your projects and tickets grow, you’ll see just how useful, if not essential, these features are.

Optimize the way you and your team use Jira with more Jira tips and tricks!

Christopher is a self-confessed nerd who’d probably take the cake on Mastermind if Star Trek: Voyager was his specialist subject. He writes fiction about time travel, conspiracies and aliens; loves roller coasters, hiking and Christmas; and hates carpet, rom-coms and anything with chilli in it. He’s written extensively for technology companies and Atlassian partners and specializes in translating complicated technical concepts, specs and jargon into readable, benefits-driven copy that casual readers will understand.