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

How can I adjust the sprints that can be seen on a Scrum board?

Michael Repucci

For a while, our company was using one Scrum board called "Engineering Scrum" for all of our Agile projects. We're now moving toward better roadmapping, including epics and versions, and finding that having multiple projects on the same Scrum board is limiting and confusing.

We've created new Scrum boards copied from "Engineering Scrum" each with filters and permissions for just one project, but not all the past sprints belonging to a project appear on the sprint report view. That is, on the "Engineering Scrum" board, in report view, there may be 3 sprints visible for Project A. But on the new "Project A Scrum" board, in report view, only 1 of those sprints is visible.

How can I make all sprints belonging to a project visible on a new Scrum board?

EDIT

I just made some progress, and possibly changed my issue. I have the status Closed not configured to a column on the board. This is because I don't want developers closing the issues; I want them to move them to Resolved, and transition all Resolved issues linked to a Fix Version to Closed when that version is released. Is there a better way to accomplish this?

Accepted answers

Nicolas Bourdages

Sprints don't belong to projects. Sprint is a value in an issue's field, and they show up in the board in which you created them, and in other boards that contain issues that belong to these sprints. If your Project A board shows issues that belong to Sprint 1, only these sprints will appear in your new board.

So, to make all sprints visible on your new board, make sure to include in that board's filter issues that belong to each sprint you'd like to see.

All comments

Nicolas Bourdages

So, to make all sprints visible on your new board, make sure to include in that board's filter issues that belong to each sprint you'd like to see.

Michael Repucci

Thank you for the information; I'm new to Jira administration, so every bit of explanation helps me understand better. I think I've got it setup like you're suggesting, but it doesn't seem to be working. The "Engineering Scrum" board has a filter of project in ("Project A", "Project B", ...) ORDER BY Rank ASC, updated ASC while the individual project boards look like project = "Project A" ORDER BY Rank ASC, updated ASC and yet not all sprints are shown on the individual project boards. Does something jump out at you as incorrectly formed?

Nicolas Bourdages

Let's say the Engineering board has sprints 1, 2 and 3. Your new board for project A only has, let's say sprint 2. Are there project A issues in sprints 1 and 3? If there are no project A issues in these sprints, then your board is behaving normally. After all, why would you need to see sprints in board A that don't contain any issues from board A? As a side note, it seems to me that using two boards sharing the same sprints has the potential to becomes much more confusing that several projects in the same board. I'll give you an example on how we do things with our own setup. We have roughly 150 projects, divided into 2 boards called "Development" and "Integration". They both use the same projects in their filter, so they have the exact same backlog. What distinguishes the boards is that the Integration board gets all issues from these 150 projects, except those that belong to the Development team, and vice versa for the Development board. We do this by adding a condition in the JQL query for the board's filter that says "AND (sprint = Dev OR sprint is empty)" Since sprints made by the Dev team all follow the same naming convention of starting with "Dev", the Development board only show the backlog and the Dev team's sprints. That's not quite what you were going for initially, but if I may suggest something: Don't share sprints between boards at all. Don't even share sprints between different teams working on the same board. The backlog of your engineering team and your project A team may overlap, but they shouldn't be working on the same sprints.

Michael Repucci

What I was actually hoping to do was retire the "Engineering Scrum" board, and have each team have its own board, which usually is just one project. I was finding that with all of our projects on the same board, planning epics, future sprints, release versions, and all things roadmap-y was getting confusing. Yet we have but 5 projects to your 150, so I'm really curious how you make the roadmap level planning work. In either case, I'm still concerned that things aren't working as you suggested they should, as there are sprints from the "Engineering Scrum" board that contain only issues from "Project A", yet those sprints are not showing up on the "Project A Scrum" board. Perhaps it's related to them being closed sprints, full of closed issues, but I was hoping to view such closed sprints/issues from the report view on the board. Since all our sprints were created on the "Engineering Scrum" board before I decided to create different boards, we weren't always careful with following a naming convention such as you suggested (e.g., "Dev"), so adding the JQL query is not so feasible. I'd love to keep hearing your thoughts. Thank you so much for your help!

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-software

jira-software-cloud