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.
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:
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.
@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: https://confluence.atlassian.com/display/AGILE/JIRA+Agile+Labs#JIRAAgileLabs-ParallelSprints
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)?
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?
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. :-(
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. :-(
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.
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?
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...
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!
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