Set different Kanban boards for one project

[Jimmy Guo]

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!

[Christos Markoulatos · Accepted solution]

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

[Jimmy Guo]

@Christos Markoulatos 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]

Glad i could help Jimmy!

[Ambika Thangasamy]

hi @Christos Markoulatos

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]

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 . 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]

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:

• How to import an ordered list into Jira
• CSV Import: Line break discussion
• Formatting guide for Jira Cloud

Hope this helps! 🚀

[Ambika Thangasamy]

Hi @Christos Markoulatos  Thanks very much for the response and it worked. One quick question not related to the same topic please. 

We are trying to restrict the Edit access for the following Issue type

1)Epic

2)Story

3)Sub-task for certain roles in the dedicated Project Space. is there the way to implement this. please can you help me with that?

Thanks in Advance.

[Christos Markoulatos]

Hey @Ambika Thangasamy 

Yes, you can restrict Edit access for specific issue types (like Epic, Story, Sub-task) in a project by using Workflow Conditions or Issue Security Schemes, but the most common and clean way is:

Use Workflow Properties

• Add a property to the status in the workflow, for example:
• jira.permission.edit.group = Developers

This means only users in the Developers group can edit issues in that status.

• You can apply different workflows per issue type if you need different rules for Epics, Stories, and Sub-tasks.

Or use Field Configuration / Screen Scheme

• If you only want to restrict certain fields (not full edit), hide them via Field Configuration for specific issue types.

Keep in mind that Jira doesn’t have a native “Edit permission by issue type” toggle. You achieve it by:

• • Separate workflows per issue type + workflow properties, or
  • Issue Security Levels (but that’s more for visibility than editing).

[Ambika Thangasamy]

Great thanks @Christos Markoulatos  for the quick response. Will check this.