Scenario: We have all of our "Projects" in 1 project. This is because all of our "Projects" are "component based" -- Android, IOS, and Platform. In the spirit of having Stories, above all "layers of the cake", we have 1 Jira Project. We then have several Scrum teams working on different sprint cycles. I was surprised to discover last night that it looks like the new Scrum board only allows 1 active sprint (even if you create different scrum baords with different filters!). For example, we have Team 1 and Team 2. As soon as I changed the Filter for Team 2 to point at the same project as Team 1, it used the active sprint of Team 1. If I changed the Sprint label for Team 2, it changed the sprint label for Team 1!? I'd hate to have to go back to separate Projects for different component teams, since I think this re-inforces the silos agile is trying to break away from, but Jira/GH may force me to :-/
The board knows which sprints exist by selecting all of the issues that match the filter, then looking at the Sprint field in each of those issues. You can easily configure the boards to be completely independent simply be selecting different issues for each board, for example the filters might be "project = x and component = iOS" and "project = x and component = Android", these boards would then operate independently.
There's some more discussion of this at this answers post.
For your scenario I'd recommend getting this split set up working rather than using parallel sprints, but I guess it's up to you.
If you've tried the split set up and you're still seeing the same sprint across the two boards then one or more issues must have both components assigned to it?
I don't think so but I can verify. The filters are using the component field. For one its Component in (Android, IOS) and the other Component in (Platform). I had just migrated the issues into a common Project and did bulk updates populating the component field so the lists should have been mutually exclusive.
Can you elaborate, or is there a white paper or something on the logic around the Sprint field and when and how it is instantiated? I have noticed there's a Sprint ID, it's a number, (its not the label you see in the UI), and it gets instantiated when the sprint starts. Is there a way to set this value to Null in a bulk update query? (I couldn't figure this out.) This would be helpful to put things back into the backlog essentially.
PS - You know I do recall, one issue being on the board. I bet this is the issue that cause the other sprint to appear on the Platform team's board. Then I exacerbated the issue by adding more issues to that visible sprint. I think your saying, had I fixed the query logic or the meta data in that issue, I then could have started another sprint on that board. Hmmm. I shall investigate.
You've pretty much described exactly how the sprint field operates. When a sprint is started the sprint is given an id and that id is stored in the Sprint field for each issue. You could edit it back to empty by doing a search like 'project = x and sprint in openSprints()' (which will get all issues that are in an open sprint in that project) then using Bulk Edit to set the Sprint field to empty.
There is a "GreenHopper Labs" option to turn on parallel sprints. Go to Admin > GreenHopper > GreenHopper Labs > Check Parallel Sprints. Although we haven't fully used this yet, it sounds and looks like this will allow for more than 1 sprint to be active at one time.
What is Opsgenie? Opsgenie is a modern incident management platform for operating always-on services that enables dev and ops teams to stay aware and in control of alerts and incidents. Opsgenie at ...
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