It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Start multiple sprints simultaneously

We have start trying out Greenhopper's Scrum rapidboard this week and it looks great.

We have 2 different teams which have there own sprint. I have created a different Scrum rapidboard for each team. It is possible to plan the productbacklog for each team, but it is not possible to start a sprint for each team because GreenHopper is limited to 1 active sprint simultaneously.

It would be better to limit the active sprints for each Rapidboard and not over all Scrum rapidboards.

8 answers

1 accepted

15 votes
Answer accepted

Hi Yosh,

You absolutely can have multiple sprints running at once, you just cannot start a new Sprint on a board that contains issues that are already in a Sprint (as you note).

The key is that the issues that are selected by the filter for the rapid board must not select issues that are already in a Sprint. So for example, a Rapid Board that selected only issues in project X would be completely independent of a Rapid Board that selected project Y. You could achieve the same with Rapid Boards that selected different components from the same project, different labels or any of a variety of other combinations (components are the best option because sub tasks will automatically inherit the component of their parent as long as the project is enabled for GreenHopper in the global GreenHopper configuration).

If you want to have two teams drawing from the same backlog you could potentially use the following approach:

  • Have one 'Planning' Rapid Board that selects all of the issues you wish to work (for example the JQL might be "project = x"). Use this board to order the backlog then set the component of each of the issues for Team A or Team B
  • Have two other 'Work' Rapid Boards, one for each team. These would filter based on the component (for example "project = x and component = TeamA" and "project = x and component = TeamB"). You can then create sprints and start them for each team
  • As a bonus the 'Planning' Rapid Board will automatically show the sprints that are started on the two 'sub boards' in its work mode

In GreenHopper 6.0.3 you could also use the new parallel sprints labs feature to have the sprints for both teams on the one board. Unfortunately this will make the velocity chart less usable because velocity is heavily based on the estimations of an individual team. We would like to improve this approach in the future which is why the feature is in labs.


Any updates on this topic? Is this still the best way to have multiple sprints simultaneously? Thank you.

@Shaun Clowes [Atlassian] are there any updates to this functionality and/or new best practices for running multiple sprints off the same project?

@Shaun: The scenario of having multiple JIRA projects containing work items to be picked up by / distributed to multiple scrum teams must be common for the majority of your customers. I think you really should provide much better support in the tool to handle this scenario. It's a pain to manually manage the separation of issues, no matter if it's handled by labels, components or some custom field - this should be handled automatically by GH.

Anyone still loolking for the answer:

Parallel Sprints are available under JIRA labs. Please follow this lnk to get started:

Please vote for this feature:



I tried making the Planning board with the JQL mentioned above, but adding 'Sprint not in openSprints()' returns nothing at all.

If I do a search for 'Sprint in openSprints()' I get back a list of all the items I was expecting for an open sprint that I was currently playing with. It seems that the 'not' in the clause isn't working correctly. Is this maybe a bug that has been fixed since 5.0.7 (I can't upgrade to 5.1 as a few plugins cause that version to break terribly)?

Yeah, sorry, that was a bug, it needs to be "project = x and ( sprint = empty or sprint not in openSprints() )" due to the way JQL processes non existent fields. I've fixed it in my original answer above too.


So, I've tried this out, but still have an issue. Setting the filter for the 'Work' rapid board and using the 'label' (or in my case, a custom field for 'team') means that all sub-issues that are created from the parent issue wont show up in the rapid board as I don't believe that they auto inherit data from custom fields. We estimate and log work against sub tasks of stories. Since these sub tasks don't have the 'team' set, none of the work is aggregated to the parent.

I suspect that I will be lynched by my dev team if I tell them that they have to manually fill in the team for every sub-task they create. Short of creating a post-function on the 'Open' transition of all sub-tasks that copies the 'team' field, I can't think of a way of getting this to work.

Is that the only way or am I missing something?

You're right, you will need to manually label the sub tasks. Agreed this is sub optimal, thanks for pointing it out. I'd suggest using Components instead, these are inherited by the sub tasks (at creation time).


The problem with using Components is that we're using them for compontents currently. ;-) I think that this is highlighting that there is a real need to be able to start more than one sprint in a rapid board without trying to hack around the edges. It's a shame to see that hasn't been prioritised yet. :-(

Are you aware that you can have multiple components on an issue? You can continue using them as you are today but add teams as components.

As I said in GHS-5410, that feature as written is unlikely to be implemented. Agreed this workaround isn't ideal but because there is an approach we're not likely to prioritize this in the immediate future.

Seriously? The work around doesn't really work. It's a nasty hack.

My worry now is that the cost for Atlassian to maintain these two versions of greenhopper will mean that one day, the classic view will be removed. When that happens, unless the ability to have more than one started sprint from a common backlog of issues has been implemented (and by the sounds of it, there's no guarentee that it will), we'll be stuck with a version of GreenHopper that we can't upgrade.

I really don't want to be stuck in that situation. :-(

I am trying to implement the workaround mentioned - do I need to change a setting for sub-tasks to inherit Components? I am not seeing this when creating new sub-tasks from the Rapid Board.

That's strange, it definitely works for me. I'm using JIRA 5.1.

Note that the subtask just inherits whatever the components are applied to the parent at the time the subtask is created, if the components are changed after the subtask is created they will not be reflected.


Actually, please note that sub tasks will only inherit the component of their parent if the project is enabled for GreenHopper in the "Enabled Projects" section of the global GreenHopper configuration.


We are running 5.1.4 GreenHopper 6.0.3 and the syntax Sprint = empty or Sprint not in OpenSprints() does not work. It appears that the field Sprint is not searchable!!! Ahh, just found the GreenHopper labs button that allows me to start multiple sprints. Thanks. Appears to be working...

What is the best way to build a filter based on Sprint information?

Are you still having your openSprints() problem? You might like to try a reindex if it's still not working.


Reindexing fixed the problem! Thanks.

Thank you very much! Its really working!

Suggest an answer

Log in or Sign up to answer
This widget could not be displayed.
This widget could not be displayed.
Community showcase
Published Apr 09, 2019 in Portfolio for Jira

Portfolio for Jira 3.0 is here!

The wait is over... Portfolio for Jira Server and Data Center 3.0 is now officially here! Platform releases offer Atlassian an opportunity to shift our strategy, make bold predictions about t...

1,521 views 14 26
Read article

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