Need help understanding boards

[Michael Arndt]

So I just discovered that I can have a board on multiple projects. I assumed that each project had it's own set of boards so being able to share boards across projects seem interesting.

What's an example of a user case for something like this? When would it be a good idea to share boards between projects and when would it not be a good idea. 

Confused.

[Nic Brough -Adaptavist- · Accepted solution]

Many places have teams that work across several projects, especially when projects are built for tracking a product or service, not for a team.  As boards do not belong to projects, you often find boards being used by teams to show all their work in one place

[Michael Arndt]

So it basically sounds like the boards represent a team and are used across all the projects the teams share. Am I understanding that correctly?

[Michael Arndt]

Followup question.

Where does your board "live"? It looks like it either needs to be assigned to a project or to my personal space. If it's assigned to my personal space will others be able to see it?

Does the board only allow you to include projects which use the same setup? Either the same workflow scheme or is it the board type (Scrum or kabana?)

[Nic Brough -Adaptavist-]

>So it basically sounds like the boards represent a team and are used across all the projects the teams share. Am I understand that correctly?

You have understood, and stated that so correctly, I'd like to make a minor clarification ("represent a team" would be "represent a team's work") and then steal the statement so I can copy and paste it a lot.

>Where does your board "live"?

This becomes a software design issue for me.  I don't really think Jira Cloud is doing the right thing with boards, and Jira Server is better in most ways.  A board should "live" as an independent entity.  It's something that the team should use, have in one place, share, but it should be something that exists without having to "live" anywhere.  For many of us, you could say it "lives in a project", but for others, it is the reverse - "a project lives in a board".  If you dump both ideas of ownership, we all win on flexibility - a board is a board and a project is a project - both can contain one, many, all or subsets of the other.

>Does the board only allow you to include projects which use the same setup?

No.  A board is a lot more simple - it looks at the issues only.  A lot of the time, a board will be "issues in project X", but do not feel constrained.  A board could be "every damn thing I have in Jira" (don't do that, it's slow, unfocussed and really boring - you will spend ages digging.  Try "assigned to me/team and unresolved, that is a far better starting point). 

The definition of a good board though is "stuff my team needs to work on".  That might be a set of projects, but it might also by a set of issue types, or things with labels, or a field that tags them or, or, or. 

TLDR - a board should show what you need to see.  Different project configs should be irrelevant (beyond including them when you need to see them)

[Patrick Ricciardi]

We have a sprint release schedule that involves multiple projects and tickets from each project are released at the same time. We use a central board to track all of the tickets from these projects. That enables us to see the status of everything from one screen.

You wouldn't want to do this if your project schedules are different for each project, having them on one board wouldn't be helpful in that case, and might even cause more confusion.

[Michael Arndt]

So essentially you have one board shared across all the projects. That seems to make sense to me. 

All our schedules are the same too.

What do you call your board?

[Michael Arndt]

Followup question.

Where does your board "live"? It looks like it either needs to be assigned to a project or to my personal space. Where does your board live?

If it's assigned to my personal space will others be able to see it? What is the purpose of having a board "live" somewhere and if the board lives within a specific project what happens if the project is deleted or closed?

[Patrick Ricciardi]

We have our board in the maintenance project. Which, is a good choice as that project will probably never go away. As, I think it does get deleted along with a project.

You can share boards in your personal space, but I am pretty sure they will disappear if you ever leave the company, so it makes more sense to choose to put the board in a project that will be around.

[Michael Arndt]

How do you handle issues that aren't necessarily related to a project? We're not a software company but I'm on leadership and we deal with discussions, ideas, etc. 

I don't see a way to really move an issue from one project to another.

[Patrick Ricciardi]

If you have permissions you can move issues using the Move command. Click on the three dots in the top right corner and select Move.

We use the board for sprints, so each issue is associated with a project. In theory, you could have a General project that would deal with discussions and ideas. Which could also be the project that holds your board.

pat

[Michael Arndt]

So I created a "leadership" board which will eventually include my team. I'm finding that the backlog is getting clogged with my own issues and I know this will cause issues with my team adopting and buying into the agile jira solution.

So based on what you're saying I think my best approach would be...

1. Create my personal project with my personal board "My Jira" or "Mike's Jira" for random things.

2. Create a "general" project with a general board for random issues.

Does that mean we'd have to operate using different sprints since the sprint is tied to the board?