Start multiple sprints simultaneously

[Deleted user]

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.

[sclowes · Accepted solution]

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.

Regards,
Shaun

[Sofia Flores]

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

[Ben Simmons]

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

[Roine Lindvall]

@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.

[FaridM]

Anyone still loolking for the answer:

Parallel Sprints are available under JIRA labs. Please follow this lnk to get started: https://confluence.atlassian.com/display/AGILE/JIRA+Agile+Labs#JIRAAgileLabs-ParallelSprints

[Roine Lindvall]

Please vote for this feature: https://jira.atlassian.com/browse/GHS-5410

Thanks,

/Roine

[Svetlana Naumova]

Thank you very much! Its really working!

[Sean deBardelaben]

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?

[sclowes]

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

Thanks,
Shaun

[Sean deBardelaben]

Reindexing fixed the problem! Thanks.

[Jake Mann]

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.

[sclowes]

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.

Thanks,
Shaun

[sclowes]

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.

Thanks,
Shaun

[Dan Burzynski]

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)?

[sclowes]

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.

Thanks,
Shaun

[Dan Burzynski]

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?

[sclowes]

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).

Thanks,
Shaun

[Dan Burzynski]

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 https://jira.atlassian.com/browse/GHS-5410 hasn't been prioritised yet. :-(

[sclowes]

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.

[Dan Burzynski]

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. :-(