So, before the JIRA Cloud redesign, we were planning on migrating all of our TFS online projects into JIRA as separate projects, and then group them into boards based on team assignments.
Since we one team support multiple sites in a portfolio it is much easier for us to have sites as their own projects and have them work off of a single sprint backlog board. However, I don't see how to do this anymore. Boards appear to be tied to a specific project.
How would we have a sprint team support multiple sites in a single sprint board?
@Alex Blanton, you can click the Boards button and then view all boards. From that screen you can click the create board button. This will create you a new board. Like before you will be able to start with a project or filter. Either is fine as they can be changed afterward.
Eventually, you will need a filter that pulls in all project issues. into your board. You can then segment the projects by swimlane or quick filter.
As far as the board being 'assigned' to a project, it will link to each project represented in the shared board. You will need to pick one to run the sprint out of though.
Depends which version of Jira you are using.
If you see your profile image bottom left, click the magnifying glass (search) > under "Recent Boards" > "View all boards". Took me a bit to find this as well.
If you see your profile image top right, "Boards" appears as a drop-down in the top navigation bar.
@Peter DeWitt On the new Jira I don't see where to create a new board except than in a single project. If as the document says that a board is attached to a project or a person it feels counter intuitive to still be able to create a board for multiple projects. The hierarchy seems just wrong and confusing.
If I'm correct, the hierarchy is like this:
Projects > Boards > Sprints > Version / Epics / Issues
If this is correct I'm still very confused on how a project manager can see in one view what the team is working on. I mean in our company we have something like 120 active projects, we can't have 120 boards with 120 sprints.
What would be the correct way to visualise what the team is working on a single view?
Without information like, the expected delivery of each project. I would suggest you let the Jira "Project" be a representation of your team. "Epics" be a representation of the projects. From there you can assign epics to sprints as needed.
As for the "Board", you can tailor it how you see fit. It's a creation based on the query you provide. That query could be pulling items that aren't even associated with the project it's in.
For Example: You can make a "Project" for Project Managers. In that project, you can make boards that are based on "Epics".
Project = "PMO"
Boards = Customers, Marketing, Finance
Customers Query: Epic = "Customers"
Marketing Query: Epic = "Marketing"
Finance Query: Epic = "Finance"
To expand on @Blake Dodley's response,
You can use filters to make boards pull in whatever projects you want. By controlling the permissions to those filters you can even manage what different users see in that same board.
share group CEO = the CEO
share group Employees = employees under CEO
filter All Epics = shared with share group CEO
filter All Stories = shared with share group Employees
board All Projects = shared with share groups CEO and Employees, using filters All Epics and All Stories
In this board the CEO can only see Epics (assuming the CEO does not have access to Stories) and the Employees can only see Stories (assuming Employees do not have access to Epics).
You can do the same thing with dashboards. The primary issue raised by @Alex Blanton is that currently boards must be associated with a project. If the board uses filters that pull from multiple projects, associating the board with a single project doesn't make sense.
It does make sense to ensure boards are tied to "active components" within Jira such as projects or users, to ensure they aren't simply abandoned and forgotten. You can associate a board with either by going to board > board settings > location > [select user].
*Edit: how to associate board with user instead of project.
Thanks a lot @Blake Dodley and @Joshua Balsillie for your answers. I'm a bit frustrated by the idea that we have to hack the platform to make it fit with our organization. Considering Projects as Teams and Epics as Projects just doesn't feel right.
Same for boards. You can create a board with a filter for multiple projects but you have to attach it to a single project or member. Jira's hierarchy is for me too flexible, it makes it hard to actually understand what would be the recommended way.
It would actually be great if the Atlassian team could document some use cases.
I have question related to this discussion and firstly thank you for the wonderfull answers.
I have created two projects ABC and DEF to work on epic and backlog item as shown in the below screenshot
Now I have created a filter which will show all he epic and line items
|Backlog item 1.1|
|Backlog item 1.2|
|Backlog item 2.1|
|Backlog item 3.1|
|Backlog item 4.1|
|Backlog item 5.1|
|Backlog item 6.1|
|Backlog item 7.1|
Now I am going to create a scrum board with the result of above filter. which as shown below
Now I will use all functionality of the sprint board, fix version and also release note to the full extent.
the question is since my boards are for two projects, will there be any unexpected error in the future based on your experience.
Thanks and Regards
I agree with the concerns raised by @Charles de Dreuille@Alex Blanton that having a board to be linked to a single project even when you can assign a custom filter to pull issues across multiple projects (in the new update to be done through assigning a location) is wrong. The users should be able to see multiple projects in a single board easily if their teams work across projects. My team members are currently not able to easily find their boards that they worked off in the past.
The previous setup for boards worked well where a user could navigate to any shared board easily. Linking to a single project and not allowing to have users to navigate to a particular board without going through a project is not working well and is a set back in my opinion. Boards should be available from the main side bar how we have access to projects and issues and not have a location be associated with single project.
So what we ended up doing is setting up a "team" project, with an aggregated project board for that team housed there from all the other actual project backlogs we have from various properties and customers. Since our sprint teams are working on multiple projects at a time, from multiple customers, this seems to be the only way to accomplish it unless I am missing something. It feels wrong to have to associate a team to a single project in order to run a sprint, but I this is what we ended up with. Has anyone found another solution?
Just a quick question. Should you still have a Scrum board for the individual projects or is it better not to have a board for those (or perhaps just a kanban board instead for project specific visuals) and simply use the top level board for all sprint planning, backlog and sprint activity?
I'm finding that if I have board on one or more of the projects that make up the top level board, and I start a sprint from there, this sprint is also displayed in the top level board which makes things a little confusing at first. Suddenly there's 2 active sprints. Makes sense when you get used to it but want to avoid this happening unless we have a break out project that needs it's own sprints and is managed independently but we still want to see status in the main board.
Hope that makes sense! :)
Yes, so what we are doing is we have a separate project for each web site. Each has its own board where we still track the stories, etc. However, we then create a different project for each sprint team. The sprint team board is setup to query the projects needed to create the sprint backlog. The sprint is then started and managed on this sprint team board.
You can still create epics in the individual project board, but if you are tracking versions/releases I would keep these on the sprint team board. It's a little counter intuitive with the way JIRA is actually setup, but it has actually worked out pretty well as we often have cross project sprints and releases as well as team members that may rotate to different teams. It would be awesome if JIRA actually accounted for this and actually thought at some point we may develop an add-in to clean up this process as it is a lot more practical.
Hope this makes sense.
To clarify - sprint planning and backlog grooming is also done at the team level and not the individual project level. However, we will sometimes do stakeholder backlog review and prioritization at the project level. I think it would depend on how you use product owner roles.
@Alex Blanton Thank you! You've put my mind at rest regarding the way I'm setting our Jira instance up. Sounds like we're pretty much set up the same way and I was concerned that I seemed to be going against the way Jira is configured but actually it's working out well this way. Again, thank you.
So, I think Atlassian's "preferred" solution is for us to use their Portfolio product to manage cross-project releases. I presume this is the reason JIRA will not allow us to add issues in one project to Versions in another. The Master Scrum board will show all the associated Versions but will not allow adding from cross-projects. I notice there are a few viable looking tools for JIRA Server that look promising. Not sure about Cloud, which is what we are using.
Another option may be to use a 3rd party tool to pull both instances and their issues and setup a roadmap dashboard:
@Blake Dodley That was my idea as well... till I noticed you can't create Epic on Epics, nor add tasks on stories, just subtasks. Subtasks don't show up in your board, so you just have a messy board with unusable stuff.
Let's say you use your project as your team and your epic as your project. Let's say you have a "Migration to Cloud" project (which would be an epic in this case).
An epic inside this "project" could be "Deploy service X", but since "Migration to Cloud" is already an epic and for some unreasonable reason you can't create epics inside epics, you need to create "Deploy service X" as a story/task. Then, let's say you want to create a "Create terraform templates" as part of this, and "instance", "roles", "security group" inside it. Like this:
Migration to Cloud > Deploy service X > Create terraform templates > Create instance
Migration to Cloud > Deploy service X > Create terraform templates > Create access roles
Migration to Cloud > Deploy service X > Create terraform templates > Create security group
You simply can't, without losing track of what you are doing. Yes, "Migration to Cloud" would be your epic and "Deploy service X" would be your story/task. Since you can't add tasks to a story/task, just subtasks (and they don't show up in your board), your board will have just "Deploy service X", instead of "create terraform templates". That means EVERYTHING needs to be done before moving, which makes no sense at all.
The idea of locking what can be inside what is completely random and against agile methodology itself. Agile is not about following frameworks, is about adapting them to your team to get the best out of it. This restriction just makes people asking WHY in a LOT of these tickets (I can copy links for questions like these or "epic under epic" for an entire day).
As you can see on the screenshot below, "Deploy service X" is still under "TODO", but "Create terraform templates" is already "in progress", and you can't see that in "In Progress" (and not even commenting the fact that you CAN'T create subtasks for the subtasks, so you even lose that information).
The fact that you need to pay for plugins (like Portfolio or Structure) to work as a workaround (like the workaround suggested in this post) just shows that the platform is simply not ready for teams with multiple projects.
If you decide to use one board per project, you will have dozens of boards (which is basically not possible to track at all) or you have to use this suggested "hack", but you completely lose the control over your tasks.
The fact that GitHub+ZenHub or GitLab have this and it's not even their main purpose (ok, it is for ZenHub) is quite concerning.
I'll keep trying to find a solution for this during my trial period, but it seems to be a complete dealbreaker.
If you guys have any ideas how to solve this WITHOUT paying more just to get on a workaround to "fix" the platform I would love to know.
Does anyone know if using the custom filters to create a single view that pulls in all projects can be extended to boards under a client account?
For context, we provide support for a platform to a few different clients. Most of them use our JiRA boards to submit tickets, requests, etc, but there a couple who have their own JiRA accounts. We are trying to merge the data from both sources so we have a more accurate vision of inflight work for better resource planning and management.
In order for you to display issues from one JIRA account within another JIRA account you will need a plug-in. Something like this would be an example: https://marketplace.atlassian.com/apps/1213346/issue-sync-synchronization-for-jira?hosting=cloud&tab=overview
Learn how to use two new reports for next-gen projects in Jira Cloud: Cumulative flow diagram and Sprint burndown chart. Ivan Teong, Product Manager, Jira Software, demos the Cumulative ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events