nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Set different Kanban boards for one project

Jimmy Guo_77grmx

I’m new to Jira and currently working in a software development team. I would like to set up multiple Kanban boards under a single project, with each board used to track different requirements.

The reason I want to do this is that I also need to track the development stages and details within each requirement. Having separate Kanban boards feels like it might help me manage and visualize these workflows more clearly.

Is this approach feasible? If not, what would you recommend as a better way to manage and track requirements and their internal development steps within one project?

Any suggestions or best practices would be greatly appreciated. Thank you!

Accepted answers

Christos Markoulatos -Relational-

Hi @Jimmy Guo, welcome to Jira! 👋Yes, you can absolutely create multiple Kanban boards in a single project. Each board is just a filter (JQL) + column mapping, so you can have different views of the same issues without duplication. When to use multiple boards

Different teams or domains share one project (e.g., “Mobile” vs. “API”).
Stakeholders need a focused view without clutter.

Avoid creating a new board for every workflow step model stages in the workflow instead.

Best practice structure

Epics = high-level requirements.
Stories/Tasks = deliverable work.
Sub-tasks = internal steps.
Use workflow statuses for development stages (To Do → In Dev → In Review → Done). Group them into 3–4 columns for clarity.

Options to visualize

One board, strong filters:

Swimlanes by Epic.
Quick Filters for components, labels, or teams:

component = "Mobile" OR labels = api

Multiple boards:

Create a saved filter per view:

project = ABC AND component = "Mobile" AND statusCategory != Done

Boards → Create board → Kanban → From existing filter.

Tips to keep it clean

Name boards clearly (e.g., ABC – Delivery, ABC – API).
Share filters and boards with the right audience.
Enable Kanban backlog, WIP limits, and auto-hide completed issues.

Alternatives

Advanced Roadmaps for hierarchy and planning across boards.
Quick Filters + Dashboards if you just need different slices, not separate boards.

Bottom line: Start with one board using swimlanes and filters. Add extra boards only if a group consistently needs a different view. Too many boards = fragmented focus.

Hope this helps! and good start on your journey

All comments

Christos Markoulatos -Relational-

Different teams or domains share one project (e.g., “Mobile” vs. “API”).
Stakeholders need a focused view without clutter.

Avoid creating a new board for every workflow step model stages in the workflow instead.

Best practice structure

Epics = high-level requirements.
Stories/Tasks = deliverable work.
Sub-tasks = internal steps.
Use workflow statuses for development stages (To Do → In Dev → In Review → Done). Group them into 3–4 columns for clarity.

Options to visualize

One board, strong filters:

Swimlanes by Epic.
Quick Filters for components, labels, or teams:

component = "Mobile" OR labels = api

Multiple boards:

Create a saved filter per view:

project = ABC AND component = "Mobile" AND statusCategory != Done

Boards → Create board → Kanban → From existing filter.

Tips to keep it clean

Name boards clearly (e.g., ABC – Delivery, ABC – API).
Share filters and boards with the right audience.
Enable Kanban backlog, WIP limits, and auto-hide completed issues.

Alternatives

Advanced Roadmaps for hierarchy and planning across boards.
Quick Filters + Dashboards if you just need different slices, not separate boards.

Bottom line: Start with one board using swimlanes and filters. Add extra boards only if a group consistently needs a different view. Too many boards = fragmented focus.

Hope this helps! and good start on your journey

Jimmy Guo_77grmx

@Christos Markoulatos -Relational- Thank you for your reply! This helps a lot and I'll try to apply those to the project I'm working on.

Christos Markoulatos -Relational-

Glad i could help Jimmy!

Ambika Thangasamy

hi @Christos Markoulatos -Relational-

I attempted to create an additional Kanban board under our project folder using a saved JQL filter, but I’m unable to see the filter in the board setup—even though it’s shared with viewers who have access to the project space.

Also, I’d appreciate your clarification on one point: if we create another Kanban board within the same project, will the test cases that are already visible on the existing board also appear on the new one?

Thanks in advance for your support.

Christos Markoulatos -Relational-

Hi @Ambika Thangasamy

If your saved filter doesn’t appear when creating a board, check:
- The filter is shared with the same project (and with you).
- You have Browse Projects permission for that project.
- The filter owner hasn’t restricted it to private.
- Try refreshing the board creation dialog after saving the share settings.
Yes, if the new board uses a filter that includes the same issues (e.g., same project), those test cases will appear there too. Boards are just views on issues, not separate copies.

Also try to use JQL to control what shows on each board, e.g.:

project = ABC AND component = "Mobile"

Docs: Create a board

Hope this helps!

Ambika Thangasamy

Thank you for the clarification @Christos Markoulatos -Relational- . I have one more question regarding importing requirements into Jira. The user stories I'm working with use Gherkin syntax, and when I import them, the acceptance criteria appear as a single-line statement rather than being formatted properly across multiple lines like:

Given ...
When ...
Then ...

Could you please help me resolve this issue so that the Gherkin structure is preserved in the Jira description field after import?

TIA

Christos Markoulatos -Relational-

Hi again @Ambika Thangasamy 👋

As far I remember, in order to keep your Gherkin steps (Given / When / Then) on separate lines after a CSV import, you just need to format the text in your CSV like this:

"Given user is logged in\nWhen they click Submit\nThen they see a success message"

Use \n for line breaks inside the quotes.
After import, Jira will show each step on its own line in the Description field.
If you want bullet points or bold text, you can also use Markdown (e.g., * for bullets, ** for bold).

If you’re working a lot with Gherkin or BDD, tools like Xray or Zephyr can import .feature files directly and keep the structure intact.

Links that might help:

Hope this helps! 🚀

George Mihailoff

Another angle: Upstream/Downstream Kanban

Building on Christos's excellent answer — if you're trying to track requirements through discovery phases and their execution separately, you might be looking at a classic Upstream/Downstream Kanban pattern.

The idea:

Upstream board — for requirements before they're ready for development. Think: Idea → Refining → Sizing → Ready. Longer cycle times, looser WIP, owned by product/analysts.
Downstream board — for work after commitment. Think: To Do → Dev → Review → Done. Faster flow, stricter WIP, owned by the delivery team.

Why separate them:

These two phases behave differently. Upstream items might sit for weeks while being shaped; downstream items should flow in days. Mixing them on one board muddles your metrics and makes WIP limits meaningless.

Setup in Jira (same project, two boards):

Create a "Discovery" workflow for Epics (or a custom "Requirement" type) with upstream statuses
Create your standard delivery workflow for Stories/Tasks
Board 1: filter to Epics only, map to discovery columns
Board 2: filter to Stories/Tasks, map to delivery columns
When an Epic is "Ready," its child Stories appear in the downstream backlog

This keeps everything in one project while respecting that discovery and delivery are genuinely different processes — not just different views of the same work.

Might be overkill for your situation, but worth considering if the "multiple boards" instinct is really about separating these two phases.

Elizabeth Minaci

I love this idea and as a new user it is exactly what I need. What kind of admin role would I need to be able to do this?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud