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

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


1 badge earned


Participate in fun challenges

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


Gift kudos to your peers

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


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!


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
Community Members
Community Events
Community Groups

Using multiple Greenhopper boards for the same project seems to share sprints

We are trying out Greenhopper and created a separate scrum board for each release of a product (which is a JIRA project) to represent the issues that are going to be a part of that release. The problem is that when I create a sprint for one of the boards, it shows up and is shared by the other boards. Is this a bug or an unexpected use of the Greenhopper boards/sprints?

6 answers

1 vote
petry Atlassian Team Aug 22, 2013

Hey John,

You can have multiple boards using the same project, however you need to keep in mind you can't have different Sprints in each board. If you start a Sprint in one board, this Sprint will appear in the other board. This because the Sprint information is stored in the issue itself, so if you have that project in another board, the sprint will be there.

To avoid this, you can try the suggestion from Shaun (see here), where you can use components to distinguish each one.

Also, we have a project currently in "Labs" to handle this restriction (see Parallel Sprints), but please note it may change from it's current implementation.

Hope that helps.

Andre Petry

Hello, If parallel sprints is enabled do you have to still define components? Thanks!

0 votes


We have same problem and I agree that this is a bug. If you have 2 boards and at edit issue screen change sprint field value of an issue from board 1 with a sprint name from board 2 then an sprint will created automatically in board 1 with the same name at board 2 and every thing you do with one of this two namesake sprints will change in another one. For example change sprint name in one and it'll changed automatically in another one. 

but you can use this receipt for solving this:

  1. First you must be sure that sprint field of each issue at most have on value.
  2. Redefine your boards by Board from an existing Saved Filter 
  3. Use an Abbreviation for naming all of your sprint. A good one can be your board name following with sprint number. For Example: Board1-Sprint1 and Board2-Sprint1 and be careful to use a pattern that remain unique during your project.
  4. It's cooked!

Andre [Additional Question],

As you suggested above, I set up mulitple boards for the same project. One board is scrum (dev work) and one board is Kanban (maintenance work). When I create an issue for the Kanban board, why does thaqt issue show up in the backlog for the scrum board?

Yes, that will work too, any method either versions, components like Andre suggested below or labels will suit you. Just rember that one task should be present only on one board specified in board filter criteria

Thanks for your responses. What I am trying to set up is the fact that we are working on multiple versions of the same product concurrently (i.e. some of the tasks/features are long term and targeted for a future release). Would it work to create a 'Release 1' board and 'Release 2' board on the same project, assign each issue a Fix Version and then filter for those versions in their respective boards? Alternatively, I am curious about the Parallel Sprints but am a little concerned about the developmental nature of them and being subject to change. It doesn't seem like what I'm trying to do would be that uncommon, so I wonder if there is a better way to do this altogether.

Depending on how this affects your process it could be a bug or side effect. This is happens only when issue which is in spring in one board is also present on another board too. So if you adjust filters for your boards in a way that one issue could be present only in one board (which was ok for us) then it wont happen. We did that separation using labels by adjusting board filters and marking issues by only one lable associated with the particular board. Hope this could help you.

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events