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; } } }

Need help understanding boards

Michael Arndt_smtys6

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.

Accepted answers

Nic Brough -Adaptavist-

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

All comments

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.

Nic Brough -Adaptavist-

Michael Arndt_smtys6

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_smtys6

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_smtys6

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?)

Michael Arndt_smtys6

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.

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)

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