Single board vs multiple boards

[Rohit Prasad]

What's the difference between a project having a single and a project having multiple boards? When to use single board and when to use multiple boards?

[John Funk]

Hi Rohit - Welcome to the Atlassian Community!

We use multiple boards when we have a large crossfunctional team working together - copywriters, designers, copyeditors, developers, marketers, QA, etc. We ALWAYS have a Master Board with ALL issues the team is working on, but it can be a little cumbersome for marketers just doing their work, or developers just doing their work. 

The main reason for the multiple boards is to reduce the number of columns that group of users needs to see, making it less clutter for them. 

[Marianne Miller]

I am one of those strange individuals who uses multiple boards, all the time.  I find that I want to look at the project statistics different ways, and I may build out different filters to base them on.  I also use boards to define columns in ways that tell me a story that may be different from the way the Product owner wants to look at them.

For example, We have some that show every status, and some that one show very high level statuses (bucketed together.

I have a different board for the active sprint, where I define the card layout with additional data and also count tickets in each column.

I also have a board that has a set of projects rolled up into one view.

and the list goes on...

I really think it comes down to personal preferences and how you want to use the data that Jira provides.  I find that you can get some really powerful metrics and keep your finger on the pulse of things.  If you identify what you need to know or what gaps you have in your current project management, you might find a way to define a board to help with that.

[Jack Brickey]

well that really depends on what you are trying to do. TBH, I rarely use multiple boards per project. Once obvious use case would be if you say had multiple teams doing their own thing. And maybe you use Components to categorize their work: team 1 = platform, team 2 = UI, team 3 = stack. Then you could create three boards and add the component to each board. Another scenario might be to have project management having a board where all issues go to first for vetting then they move to development board for implementation. Again, there are a number of situations where you might find this useful. It is hard to say how it might be useful to you w/o understanding your environment/processes.