Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,460,008
Community Members
 
Community Events
176
Community Groups

How To Guide: How to manage sprints across multiple boards

In this guide we will look into behavior of the sprints and how they work together with the scrum boards.

Situation 1

Let's assume we have one project (name: Scrum project, key: SCR) with three issues and two scrum boards (SCR A board and SCR B board). These two boards use the same filter (project = SCR ORDER BY Rank ASC), which means the boards show the same set of issues.

  • What happens, if we assign some issues to the sprint in the first board's backlog?
  • Will this action affect the second board's backlog somehow?

Let's navigate to the board's backlog. In the beginning both backlogs look the same:

sc1_backlog_a.png sc1_backlog_b.png

Create a sprint called Sprint 1. This newly created sprint is visible on the first board's backlog, but the second board's backlog remains unchanged.

sc1_sprint_create_a.png sc1_sprint_create_b.png

Add all the three issues to Sprint 1. Now the sprint is visible on the both boards' backlogs.

sc1_sprint_issue_add_a.png sc1_sprint_issue_add_b.png

Start Sprint 1 in the first backlog. Sprint 1 is started on the both boards' backlogs.

Conclusion

Sprints aren't dependent on a specific board or project. It's therefore possible for a sprint to be displayed in more than one board. It is still one entity though, and changes made to it in one board will be reflected in the other too.

Connection between issue and sprint is stored to issue's field called Sprint.

If issue is assigned to a sprint, this sprint is visible on all scrum boards, which show this issue.


Situation 2

Let's continue, where the first situation ended (so we already have SCR project with two boards and sprint called Sprint 1), and let's create another project (name: Scrum project 2, key: SCR2) with three issues and one scrum board (SCR2 board). This board shows only issues from the second project (project = SCR2 ORDER BY Rank ASC).

  • What happens, if we create sprint with the same name (Sprint 1) in the second project's backlog?
  • What if we search for issues assigned to Sprint 1?

In the beginning there are no sprints in the second project's backlog.

sc2_backlog.png

It is possible to create another sprint with the same name Sprint 1 in the second project board's backlog. Let's assign the issues from SCR2 project to this newly created sprint.

sc2_sprint_issue_add.png

If we search for issues assigned to Sprint 1, we get issues from both projects.

sc2_issue_search.png

Conclusion

There can be multiple sprints with the same name. It is therefore recommended that sprint names indicate the project or board name, in order to avoid confusion. 


Sprint identification

If you want to be 100% sure, with which sprint you are working, check the sprint's id (= sprint's unique identifier). There are more ways, how to obtain sprint's id.

Issue detail view

If issue is assigned to some sprint, you can get the sprint's id from the issue detail view (no matter if sprint is future, active or completed). Navigate to the issue and highlight over the sprint's name - you can see the sprint's id in the shown URL (id = 13)

id_issue_detail.png

 

Scrum board's backlog

After sprint creation you can view the issues assigned to the sprint in the issue navigator. The generated JQL for issue search contains sprint id (id = 13)

id_issue_navigator.png id_issue_navigator_2.png

Scrum reports

You can also see the sprint id in the URL, if you navigate to the Sprint Report (select Reports in the left menu -> Sprint Report).

id_sprint_report.png

REST API

If you send GET request to the endpoint

/rest/agile/1.0/board/{boardId}/sprint

you get information about all sprints in the board (but you need to replace the parameter boardId with the id of the appropriate board)

id_rest_api.png


Situation 3

Let's continue, where the second situation ended. Let's assume we still have both SCR and SCR2 projects, 3 issues in each of them, and 3 boards (two for the first project and one for the second project). We create another sprint with name Sprint 2 and another 3 issues in SCR2 project and assign them to Sprint 2 in the second project board's backlog.

  • What if we move this issue from the second SCR2 project to the first SCR project?

In the beginning Sprint 2 is visible only on SCR2 board.

sc3_sprint_issue_add.png sc3_sprint_issue_add_2.png

If we move SCR2 issue assigned to Sprint 2 to the SCR project, Sprint 2 becomes visible on all the boards.

sc3_move.png sc3_move_2.png

Conclusion

Once you move an issue, the sprint value remains the same. The same sprint can be visible on more boards.

If the same sprint is visible on more boards and you don't have sufficient permissions for all the projects, there can be several problems like it is not possible to

  • start a sprint

sc3_start_sprint.png

  • complete a sprint

sc3_complete_sprint.png

  • change order of sprints

sc3_move_sprint.png

If you want to work with a sprint, which includes issues from more projects, you need to have appropriate permissions for all the projects.

11 comments

In Situation 1, why did the second board only see Sprint 1 when you added all three issues to it? Why did the second board not see Sprint 1 when you added the first issue to it? 

Hana Kučerová Community Leader Jul 31, 2021

@Matt Doar__ LinkedIn I'm sorry about that, it didn't come to my mind, that it would be confusing. Of course, one issue with Sprint 1 is enough.

@Hana Kučerová In situation 1, is there a way to force sprint 1 to show up on the second board without having an issue from the second board already in it?

Alternatively phrased, how can I add issues on the second board to sprint 1 if it doesn't show up yet?

Like Faten Afifi likes this
Hana Kučerová Community Leader Feb 19, 2022

Hi @Matthijs Damen ,

>>> In situation 1, is there a way to force sprint 1 to show up on the second board without having an issue from the second board already in it?

I don't think there is any way.

>>>Alternatively phrased, how can I add issues on the second board to sprint 1 if it doesn't show up yet?

You don't need to use board to assign an issue to a sprint. You can for example do it in the detail of the issue (field Sprint).

@Hana Kučerová : If i start sprint 1 in board A will it also start sprint in board B.

Hana Kučerová Community Leader Apr 19, 2022

Hi @Rahul Kumar . Yes, that is correct.

Hi,

I think I have same issue described above.

If I have one project and 2 boards (A &B) . Each board have its own components . So board A has issues with component a1 as an example. Board B has issues with component b1. Now I want create a sprint to be visible  for the 2 boards. 

I created the sprint 1 from board A.  Now I can move issues from backlog of board A to sprint 1 because sprint 1 is visible  from A.  Then I go to B later but I cannot move issues from B backlog to sprint 1 because it is not visible ??????????

As a work around I have to go to board A and create an issue in sprint 1 that has component b. So now sprint 1 is viable from board B.  

 

 Should the sprint be feasible to all the boards once it is created (when it is empty) ????  

Hana Kučerová Community Leader Jul 24, 2022

@Faten Afifi Sprint 1 cannot be visible on the second board, because your boards show different set of issues. I would recommend you to have only one board with both components and use quick filters to filter the issues. But I don't know your use case exactly.

Is there an overview of all the sprints? And all the issues in that sprint from all boards and projects.

When Finishing a sprint the sprint contains xx issues Done and yy not Done. But I cannot find those issues. We have 30 projects and 50 boards ;-)

You say "Sprints aren't dependent on a specific board or project. It's therefore possible for a sprint to be displayed in more than one board. It is still one entity though, and changes made to it in one board will be reflected in the other too."

But the Roadmap feature on scrum boards in JIRA Cloud doesn't see things this way.

Board A has Sprint 1, and displays all project tasks. Board A's Roadmap will not display because there are too many tasks in the backlog.

So we make Board B, which displays tasks only for Component X.

But tasks for Component X assigned to Sprint 1 will not display on Board B's roadmap, because Sprint 1 was defined on Board A. If we create a sprint called "Sprint 1 - Component X" on Board B, and assign the tasks to that sprint, they will now display on the roadmap. But we don't want to have to manage custom sprints per board, as this messes with other project reporting.

Hana Kučerová Community Leader Dec 13, 2022

@Katrina Archer This tutorial has been created on the server version some time ago. Anyway, I can confirm the described behavior for the Roadmap functionality in the cloud version. From my opinion - it is not correct and I would expect to see the sprint data on the second roadmap too.

You can try to suggest this change to Atlassian, but personally I would recommend you to start using Advanced Roadmaps. There are so many more possibilities and the behavior is correct.

Like Katrina Archer likes this

Comment

Log in or Sign up to comment
TAGS

Atlassian Community Events