Hi there, 
We have successfully created an Add-on that solves for this. We had the same issues with managing multiple projects and teams using different boards. Please feel free to try and provide your feedback. 

Link:
https://marketplace.atlassian.com/plugins/early-bird-planner-prod/cloud/overview

Our need does match the title and is: Multiple teams each with their own board. These boards span multiple projects, with overlap between the teams on the projects. Because of the way sprints currently work, the sprint from one Team shows up in the other Teams boards.

Our teams just ran into the same issue, although we want separate teams to have separate boards with separate filters that aren't necessarily fully exclusive. It's crazy that having multiple separate teams that share one project/component is so difficult to manage, especially since other tools I've used do this just fine.

https://answers.atlassian.com/questions/33142331/cant-start-my-sprint-because-of-another-teams-active-sprint

I see this issue is an old one. Are there plans or not to implement this?

Thanks.

Hi Atlassian,
Is there any plan to develop this feature ? This is causing a lot of issues for our dev teams here.

Vote up for this feature.

This is really needed for matrix organizations

My approach to this with 6.2 is to have a select custom field named Team and to create Swimlanes based on Team=TeamA, Team=TeamB etc. Card coloring by Team also helps plus Quick Filters. That gives me multiple ways to focus on a single team in a board. Still this is for a single sprint.

Just adding a note here for if/when this gets picked up for future use with a couple of our use cases for overlapping sprints. In our world, every code change is tied to a JIRA card and every release is tied to a sprint. If it doesn't have a sprint, it doesn't have a release.

Use Case 1: Sprint "done", regression uncovers bug that needs to be fixed
-Scenario
--Sprint 1 ends on Thursday 1/15 and releases on Tuesday 1/20
--Sprint 2 starts on Friday 1/16
--Sprint 1 is "complete" but on Monday 1/19 we uncover an issue that needs to be resolved (ISS-10) before golive. This occasionally happens with regression testing or something slipped through. We leave Sprint 1 open so that a developer can go in an make the fix via an issue in Sprint 1. They won't get credit for it in the burndown of Sprint 1 or Sprint 2 (which I don't have a problem with) but if we are forced to close Sprint 1 before we start Sprint 2 things become a mess. If ISS-10 is created as a card in Sprint 2, it is not really true because the code change will go out with Sprint 1.

Use Case 2: Hotfix
-Scenario we are in the midst of Sprint 20 and an unscheduled release is identified
-Let's say we just released Sprint 19 and are in the midst of Sprint 20 and an issue crops up that requires a deploy. What we do on the classic boards is go in and create Sprint 19.1 that will contain the issues for the hot fix. This minisprint may only live for one day but all of the issues for the release will have a sprint.

In both of the above examples, the sprint teams won't get credit for the cards in their current sprint (which I am fine with because this averages out over time and is why velocity is never 100% of available time) and we know that.

The Parallel Sprints feature seems like it should allow everything to work correctly for us but when that feature is disabled, I wanted to provide some use cases to help in crafting a longer term solution.

In general many companies are working in larger environments with multiple teams, sometimes with independent schedules. In our case the hardware developers and the software developers. They are working towards the same milestones but in between the schedule for a "device driver" (SW side) is independent of the schedule for a "Lab prototype board" (HW side). Therefore I have added another feature request GHS-7203 which is loosely related to this one.

Thanks, sclowes. I somehow missed your post, so thanks for pointing it out. This is exactly what I was looking for.

Hi rparsons@posportal.com, did you see my comment above? This has been implemented in a rudimentary form already. Check out the labs feature for Parallel Sprints in GreenHopper 6.0.3.

Thanks,
Shaun

Just adding my voice to the rest here. We really need the ability to run multiple sprints at once from a backlog that comes from a single project. I like the new UI, but this one limitation really cramps our process.

dmsheril; i wouldn't use parallel sprints for this 'pre-planning', i would suggest creating a new upcoming sprint.

dmsheril: As I commented above, this has been implemented in a rudimentary form already. Check out the labs feature for Parallel Sprints in GreenHopper 6.0.3.

Thanks,
Shaun

Agree agree agree that parallel sprints is an essential feature! I am new to Greenhopper and don't have experience with the classic mode; am coming to the close of my first sprint using the agile board and just discovered this limitation in the course of preparing for our next sprint. I really like the agile board otherwise so I hope this gets fixed soon!

I have to agree, being able to schedule multiple sprints on the one board will bring much consistency between the usage of the new boards and how many people worked with the classic boards.

swmsimod I've decided to wait until the feature is implemented properly by GreenHopper. The work around requires a bit too much hacking with groovy scripting (to get children inheriting parent data that allows them to be shown in the rapid board). I might give the Parallel Sprints labs feature a quick play with to see if that solves the problem but given the caveats mentioned it sounds little bit like a half hearted hack.

swmsimod: No story at the moment but it's something we have on the internal roadmap. You might like to take a look at the latest labs feature for Parallel Sprints in the same rapid board.

@Shaun Clowes, do you have a ticket number I can track for this? "We do intend to address the ability to run multiple concurrent sprints from a common backlog. "

@Dan Burzynski - have you figured out any sort of work around to this? I started implementing the new version today and have the same issue, we run the exact same setup it appears, lucky us!

With the latest version of GH there is now the ability to have multiple active sprints in a project. You can also select if you want to see all active sprints or just a particular one in work mode.

I agree with some way to be able to tell the board what sprints it cares about since we have teams with multiple pods that would only want to see their sprints on the board.

It's actually very useful to be able to share sprints from board to board so we don't plan on limiting them to particular boards. We are thinking of potentially having labels for sprints so that boards can choose which labels to subscribe to, but we don't plan on implementing that in the immediate future.

Apologies Shaun, I got confused trying to explain how I would like the rapid boards to work. Ideally, the work mode could know which rapid board created the sprint, perhaps by a field on the ticket that stores the id of the rapid board, or perhaps a rapid board to sprint mapping table?

sbenskin: That's exactly what it does. The board knows the sprints to display on work mode by selecting the issues that match the filter then looking at the sprint field in each of those issues. Each sprint found will be shown on work mode.

We're still finding it difficult to adopt the rapid boards; I still don't understand why the work mode simply selects the active sprint to display by project. Wouldn't it be fairly easy to select the active sprint by project AND the filter query used by the rapid board plan mode?

@Jakob; i suppose you've defined a filter for your rapid board here?
You should edit that filter (in JIRA) to contain the 'component = ' part.

@Shaun Clowes: Thanks! We tried again today and as long as we used a filter that ensured the stories were not duplicated between boards, we were able to define completely different sprint schedules for each Scrum Board.

@Jakob: I put the component=Teamname as part of the JQL of the filter that the Scrum Board is based on. So, I have 4 saved filters (one for each scrum team) that ensure I have different stories returned based on the value of Component. Then, I have 4 scrum boards defined (each is based off of one of the filters). Thanks to Shaun I tried this again and realise that I can define completely different sprints and start/end dates.

@Edvin Stol; There can I find the advanced search? I cannot find it.
http://awesomescreenshot.com/00ef90lc1

@Jakob; you do use the 'advanced searching'?
component = Maintenance should work there.

@Heath Spangler how exactly do you compone the syntax? I just tried to enter component = Maintenance which is one of our components in the search field but i do not get anything.

do i need to put " or something?

hspangler: Could you explain what you mean by "This works very well, but we cannot have different sprint start and end dates for each of the rapid boards"? You can definitely specify any start and end dates you like on each of your four boards.

You can then have another board which does not filter by component and it will see all of the sprints executing on the other four boards.

@Jakob: Yes, the filter query for each scrum board includes JQL for component = TEAMNAME. We use Team Names in the component field to push stories to different teams. So we have 4 teams and 4 scrum boards, each showing only their own stories.

@Heath Spangler: How do you apply the filter/search in the Rapid Board search? Do you enter JQL into the search field?

I'd like to echo Lisa's earlier comment:

"This "improvement" to Jira is going to necessitate either a complete change in how we manage project execution, or a switch to some other issue tracking application when the Classic boards are removed."

We manage our projects within "Versions" for that quick top down view and have literally 100s of backlog items per project that we need to reference as we start a sprint within a version or a new version. This new single view of a project and the hoops we have jumped through to properly reference backlog items and simultaneous sprints restrict our ability to use this new version of GH.

We are sticking with Classic until this functionality is restored.

Mike

I see that we have a need for this feature for a different reason from others on the list.

We have 4 scrum teams on a single project (working on a single version of our product). Due to the logistics of sprint planning and demos, we stagger the sprint dates for the teams.

So Team 1 and 2 start on Monday... but Team 3 and 4 start on the following Monday...

We're already using components to assign stories to teams and can actually use 4 different Sprint Rapid Boards with a filter on the component to show only the stories for each team. This works very well, but we cannot have different sprint start and end dates for each of the rapid boards.

In contrast to having separate sprints per rapid board in the same project, I've proposed a slightly different solution in GHS-5828. Please discuss and vote if you find that useful.

You could do that as well, if you have a sprint planning for the teams combined.

@Edwin Stol,

The way I understand the current work-around is to have a rapid board for "planning", the query contains something like "label does not contain Team1 and label does not contain Team2". In this board, you look at each ticket, and add either Team1 or Team2 to the label field.

Next, you have two separate rapid boards, one with "label contains Team1" and the other with "label contains Team2" and use the rapid boards as intended (plan, work, report modes).

It kinda works and when you think about it you're first planning which team will tackle which tickets, and then creating sprints from their separate backlogs.

I get what you're aiming at.

The way i see it, you have several options:

• you 'label' the stories for Team 1 with the component (or label) 'Team 1', and include this in your Rapid Board filter. Same for Team 2.

• you exclude the sprint(s) created for Team 1 in your filter for Team 2 (project = X and sprint in (161))
  That would require you to edit your filter every time you create a sprint for Team 1, but you don't need to label them.

Both require an adjustment of your workflow that's not feasible in my opinion; i'd continue using the Classic mode until GHS-5542 is realised.

@Edwin Stol I have tried this, creating two separate boards (within the same

Rapid Board 1
-Sprint 1

Rapid Board 2
-Sprint 1 (Same one as in Rapid Board 1)

within the same project, but they share the same active and planned sprints.

Is this a config related issue that I can fix to realize this?

What we want:

Rapid Board 1

• Team 1 Sprint 1

Rapid Board 2

• Team 2 Sprint 1

@Jakob; it would require 2 seperate Rapid Boards, or you should wait for GHS-5542.

@Shaun Clowes If we just scrap our old setup mentioned above, with one main project and multiple versions as sprints, how should we set up the project below?

We have two teams, one project and 2 sprints for each team. Sprint 1 and 2, team 1 and 2.

Project name: "New look on the start page"

Backlog - Item 1-20

Dates October 1 - 15
Sprint 1 Team 1 Item 1-5
Sprint 1 Team 2 Item 5-10

Dates October 16 - 30
Sprint 2 Team 1 Item 10-15
Sprint 2 Team 2 Item 15-20

Would this require 2 Projects with separate backlogs and two Versions in each?

Like others here, I miss the ability to roll-up data so we can see a "big picture" milestone view, and a weekly work view.

What was cool about the classic boards is you could toggle between a single active sprint view, a future sprint, or the big rolled up milestone view throughout all the boards.

We have been using Jira successfully to manage a virtual team for several years now. I tell everyone that the reason I can manage multiple virtual teams of company employees, subconsultants, and temporary personnel is because of Jira. One of the strengths of Jira is that the "classic" boards allowed a lot of customization and control. I am concerned at how the Rapid Board is taking that control away from the user, and essentially mandating a scrum process.

Since no 2 people on my team sit together, the ability for Jira to capture everything we do, and everything we have to say about it, is paramount.

We create "versions" (sprints) to track time spent not associated with development, Out of Scope items the customer would like to have, the process of preparing requirements, actions we are waiting on from our customer, preparation of user manuals, and of course development stories, bugs, and enhancements.

As you can see, this is a disparate collection. Putting them all on one rapid board just make a board of 1,000 issues with no focus.

Two of us have spend the last 3 days trying to force the rapid board to allow us this custom approach to managing our project using filters and multiple boards. Everything we try bangs into "nope, can't do it".

This "improvement" to Jira is going to necessitate either a complete change in how we manage project execution, or a switch to some other issue tracking application when the Classic boards are removed.

The suggestion in https://answers.atlassian.com/questions/45095/start-multiple-sprints-simultaneously is not working for us, as even with the filter, we cannot start multiple sprints on different rapid boards. Perhaps there is a setting, something in the filter, the way we setup the rapid board - but the amount of resource time it is taking to figure this out is untenable.

It is disappointing to me that Atlassian has released the rapid boards without the full expected functionality. Yes, one of the strengths of Agile Development is the ability to do interim releases. But when the interim release removes well-used functions, it provides a decrease in value. I would never do that to my customers.

I am a long-time supporter of Atlassian, and have relied on Jira and Confluence for project management for a long time. I am very concerned about the impacts this GreenHopper release is going to have on Jira's utility.

We too use the same configuration that Dan lists above.

We use the same setup as Dan mentions in the post above this one.

I'm not doing any manual calculation. As I mentioned above, for each sprint cycle, we set up multiple 'versions' based on a conflation of the sprint number and the team name. We then drag in the issues that we want to work on in to the appropriate 'version'. This allows all teams to have their statistics/progress/burn downs/etc partitioned off from each other.
I can then select the sprint/team version that I'm interested in seeing in any of the charts.

So, the thing that has been removed is the ability for me to have multiple sprints in the same project running concurrently. Maybe you guys didn't realise that you'd built your product in such a way as to allow this, but you did... And it's going. And I'm sad.

It's good to know that you do intend to allow for this functionality. Where's the ticket so I can keep a track of it and thus know when it's safe to upgrade GH?

dburzynski: The value chart doesn't exist for a specific team, I'm confused at what you're saying here. The value chart across 'child' versions is used to see inter sprint velocity so it won't work in the scenario you describe because the children are different teams. It sounds like you must be manually calculating it.

No, Atlassian doesn't have account managers, or a sales force etc. This forum is probably one of the best ways of having your say.

To be clear, no feature has been removed here, just the new approach doesn't accommodate what you're looking for.

We do intend to address the ability to run multiple concurrent sprints from a common backlog.

/me looks at the value chart for a specific team in the current sprint on his Jira instance

Works fine, and has been for years. It also lets me see it as an aggregated view for all teams in the current sprint. Like I said, the only thing that doesn't work truly independently (team-wise) is that in order to avoid head-aches, all teams sprint cycles are in sync with each other.

Putting on my "customer that's in a flap because a feature that's vital for us has been removed in the latest version of the software" hat (it's a big hat), I really need some kind of assurance that Atlassian will be building back in the ability (however it's worded) to run multiple concurrent sprints from a common backlog of issues in such a way that it is possible for each team/scrum master to see how any of those sprints are currently doing (whether that's on one or multiple rapid boards). If there's an existing ticket out out there that represents that wish then please point me at it so I can click the 'vote' button over and over again for the next couple of hours.

(As an aside, do Atlassian offer an account manager service, because this is exactly the sort of thing I'd like to be talking to an account manager about directly rather than throwing my toys out of the pram on a public forum?)

P.S. Sorry... This whole GreenHopper upgrade has thrown a rather massive cat amongst my previously calm and cooing pigeons so I'm a little RAAAAA at the moment.

dburzynski: In your example things actually don't work 'independently'. For example you cannot use the value chart to calculate per team velocity.

As I commented in my workaround, components are a better approach because they are inherited by sub-tasks when they are created.

To be clear, this story as it's worded (i.e one sprint active per board) is unlikely to be implemented. The fact that boards see each other's sprints is a very useful outcome, particularly for scrum of scrum boards. When we look at this we'll need to choose another approach.

At this point, I'm not upgrading to GH6.

But yes, we have to use the 'classic' boards still as the rapid boards remove functionality that we've been relying on for the past few years. I don't want to 'upgrade' just yet as the classic version seems to be somewhat of a second class citizen in the menu structure and I don't want to shake user confidence in the product by having to explain that we still have to use the old version (with its friendly "we're not going to develop any more features for this, stop using it" message at the bottom) because of missing features in the new one.

/me cries

I want shiny new things that work! (Or at least, work for us without us having to completely change the way in which we work.) Tools should help, not dictate!