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

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?

1 answer

1 accepted

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. 

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?

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.

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!

I see. It seems there are challenges unique to your situation. Perhaps getting support directly from Atlassian Support might shed some light on this. As for our own roadmap planning, since any given sprint may contain issues from 20 to all 150 products, we can't really use versions. Our products are games developped in different eras, and version 03.01 of one game has no relation to version 03.01 of another game, so we can't use versions at all for planning (at least not in JIRA; we have another in-house tool to handle deliveries and version assignation of these deliveries). We nearly only use versions for bug tracking. We use Epics to represent deliveries. That being said, our business is quite strange with that many products under development at all times. You might be better off getting tips from more general Agile concepts. Atlassian has lots of blog posts, and I think this one is a good starting point. http://blogs.atlassian.com/2013/09/how-we-do-project-management-at-atlassian/

Cool. Thanks again for the feedback.

It looks like my issue might be a non-standard use of the statuses and the columns in an Agile project (see edits above). Any recommendations?

Not having the Closed status mapped to a column won't prevent developers from closing issues. They could use the menu to change the status instead of drag and dropping. If you want to prevent a certain group from using a transition, you need to configure a condition (https://confluence.atlassian.com/display/JIRA063/Advanced+workflow+configuration#Advancedworkflowconfiguration-conditions). User In a Project Role is a good choice. As for closing issues with a resolved version, that's quickly made with a bulk change in Issues, if you query for "fixVersion in releasedVersions() AND status = Resolved". That sounds more simple than to script a conditional post-function.

You're exactly correct. I added the Closed status to the Done (right-most) column, but changed the Workflow permissions to add a condition on the transition to Closed that requires Project Role Administrator permissions. This serves my purpose, and the sprints that were previously hidden are now visible on the Report tab, while non-Admin Project Roles cannot transition to Closed. Thanks for your help!

Glad to give back to the community. I had lots of support for my own issues here.

Suggest an answer

Log in or Sign up to answer
Atlassian Community Anniversary

Happy Anniversary, Atlassian Community!

This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.

Read more
Community showcase
Sarah Schuster
Posted Mar 28, 2018 in Jira Software

Can a company’s culture make or break agile adoption?

Can a new-to-agile team survive and thrive in a non-agile culture? If so, what advice would you give to those trying to be agile in a non-agile culture? What's the key(s) to success? Share your thoug...

12,068 views 15 13
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you