Portfolio handling of concurrent ongoing sprints

[Anders Baisgaard]

Hi there

I'm using Portfolio 2.0 to handle three teams called Frontend 1, Frontend 2 and ServerSide.
The three teams run off of two boards in JIRA Agile - Frontend board and Serverside board.

My question revolves around the two frontend teams using the same board for planning and working in sprints.
That means that the board has two active/started sprints at any given time 
The naming strategy of our sprints are like this F1-Dubai-01 (meaning Frontend 1 - name of the current release - sprint number) 

In portfolio I see the two teams in one lane each, as expected. But the current sprint is the same for each team(in this case team Frontend 1's sprint). This means that I don't see Frontend 2's current sprint anywhere in the plan F2-Dubai-01 (I suspect that Portfolio just picks the first current sprint or maybe the first created?)
team scope view.JPG 

That being said it's not like Portfolio doesn't know about the other sprints.
Seen if I try to assign a story to a given sprint. I get a dropdown containing all created sprints in the board - also the one missing from the scope view

sprint_selector.JPG

I can't change the way we use the board(with two ongoing sprints) since it makes it easy for us to use a common Frontend-backlog.
So my question is how do I configure Portfolio to handle the "Frontend-setup"?
Can i assign a team to a sprint from the board?

Thanks in advance

Regards
Anders 

[Bree Davies]

Hi all, 

Just letting you know that parallel sprint support has now been added for Portfolio for JIRA cloud customers. 

You can now assign an active (or conflicting) sprint to one or many teams, as well as assign future sprints to teams via the team card. 

You can find more information and documentation here:

https://confluence.atlassian.com/jiraportfoliocloud/resolving-parallel-sprint-conflicts-901486792.html

Look forward to hearing your feedback!

Thanks,
Bree

[Rhys Christian]

Hey all,

Just want to keep you in the loop that we've prioritised this problem. While it'd be preferable to use a native solution, for the interim I've attached a workaround guide for anyone that considers the lack of this functionality as a major issue/blocker: .
This is especially recommended for server customers since the native implementation for server will be slightly later.

If I correctly understand the requirements brought up in this question, this should provide most functionality you're after. Please let me know if you encounter any problems or if you have any questions for this.

Kind regards,
Rhys

[declanmch-boi]

Your solution is working really well for me.

Thanks

[Gal Zhovnirovsky]

Thank you for this workaround! It works great when I select Capacity View, but it doesn't quite work under the Schedule View.  In Capacity View, the work is divided among our teams, but in Schedule View, the work is all collapsed.  Is this a bug?

[Rhys Christian]

Hey @Gal Zhovnirovsky - From your screens it looks like the reason for this is that no issues are assigned to Team 2 - all 3 stories are assigned to Team 1.

To fix this you can either assign at least one issue to Team 2 or to Team 2's sprint (a sprint would first need to be created on the team's board).

[Gal Zhovnirovsky]

Hi @Rhys Christian! Thanks for getting back to me. 

I am just toggling between capacity and schedule view.  Notice on the capacity view the capacity is split between 2 teams while on the schedule view it is not.   I already assigned a task to team 2's sprint....

[Jelena Kutlaca]

Hi all, 

Thank you all for your comments and questions, they guided us into the right direction and we have managed to set up Portfolio for 2 parallels teams. 

We had separate filter for each board and one was quite straight forward

project = Project_1 AND component = Component_1 ORDER BY Rank ASC

The second one was a little bit more complex and they were some old sprints which Portfolio has imported what caused confusion. 

project in ("Project_1 ", "Project_2 ", "Project_3", "Project_4") AND (component in (Component_2, Component_3)) ORDER BY Rank ASC

We have created one additional board for the second team with simple filter project

= Project_1 AND component = Component_2 ORDER BY Rank ASC and imported user stories from this board. After this action, he user stories were properly imported and everything was properly calculated. 

We will continue to use this tool for tracking.  

[Paul Weiss]

I would like to +1 this item. Portfolio is a great planning tool. Anyone running a single project with multiple teams will run into this issue, and using a filter and another board is just too much admin work to keep a backlog organized.

Please consider ranking this feature higher in your development plans.

[Rhys Christian]

Hey Anders,

Unfortunately we currently don’t have a solution for handling concurrent sprints from the same board. Now that parallel sprints are implemented in JIRA Software we intend to implement functionality to handle this but we don’t have a good answer yet. You’re correct that right now Portfolio just picks to first sprint created.

For now the best recommendation we can offer is to split up your issues into a second board and associate one of the team’s issue source with that second board. The boards will need to have unique data so the boards filters will need to be configured.

If you’re not already using labels, I recommend using a label (e.g “team2”) to filter team 2 and changing the filter for team 1 board to include “labels is not empty”. This will allow you to use Team 1 board as the the common backlog, then set the label for all issues that will be completed by team 2 when that information is known. This will allow you to have different team lanes with distinct sprints:

image2016-7-5 11:25:42.png

We recognise that this isn’t optimal for your use case but it’s the best setup we can offer right now. Please let us know if this works/doesn't work for you.

Thanks

[Anders Baisgaard]

Hi Rhys

Thank you very much for the constructive reply.

I've dived a bit into your proposed solution with the labels, with one of the teamleads. But I'm afraid that it'll be too much overhead to toggle labels on issues each time they add them to their respective sprints. Instead of just dragging tickets from the backlog to the sprint in question - as it's done today.

If I can influence your priorities even the slightest, I'd very much like to vote up, the feature to handle parallel sprints from the same board in Portfolio   or even a hint towards when there'd be a chance of it being implemented

Cheers

/Anders

[Adrian Lazar]

+1 from my teams also. We are in the same situation as Anders & co.

[Adrian Lazar]

We are starting a one year project on which we'll have multiple teams. We'd love to leverage the functionality of Portfolio + JIRA, but Portfolio still falls short when it comes to handling multiple concurrent sprints on one board. Any updates or new recommendations on how to make this work other than using a filter on a specific field (i.e.: component, label, or custom field)?

The concern using a filter on a field is that team members will won't be entering the correct value into the field, and then we'll start missing JIRA issues in both the plan and in the actual Sprint.

[Jelena Kutlaca]

In my project, I have 2 teams which are using 2 different boards and running concurrent sprints. 

After all issues have been imported in JIRA Portfolio 2.0 the duration is calculated like the sprints will be running as consequent order rather than in parallel. Also, My JIRA is configured so we are using parallel Sprints. 

Could you please help with this issues as current project plan is inaccurate?

Thanks in advance.

[Bree Davies]

Hi Jelena, 

If you have two teams from two different boards, you shouldn't have a parallel sprint issue as the problem described above is created when you are running multiple active sprints from the same board. 

Do you have any dependencies set up between your teams? Have you configured your plan to use Stages?

Thanks,
Bree

[Adrian Lazar]

We've noticed that using filters seems to lead to other issues, i.e.: incorrect forecasting, ghost/mirrored sprints. For example:

• Main Product Backlog: A_item, B_item ... A has a label of team1, B has a label of team2
• Team A Backlog: displays items from Product Backlog labeled for team1
• Team B Backlog: displays items from Product Backlog labeled for team2
• Create sprints on both Team A and Team B boards

Results:

a) The two created sprints show up on the Main product backlog board

b) When reviewing Team A's velocity on the Team A board > Velocity report, we can see Team B velocity as well

Workaround (painful?): We've overcome this by moving team1 items from Main Product Backlog into Team A backlog. When Team A finishes the item, we move it back to the Main Product Backlog.

[Jelena Kutlaca]

Hi Bree and Adrian, 

Many thanks for your replies.

Unfortunately, my Portfolio still does not calculate the parallel Sprints therefore here is more details about the way JIRA is structured. 

1.  All our user stories are under one Epic in Jira. Could this results in that Portfolio does not estimate that we need parallel Sprints. 
2. We have one backlog with the user stories for 2 teams. Each team has its own board and its own storied what means that stories are not shared. 
3. These 2 boards are used for the import in JIRA Portfolio. 
4. Parallel Sprints are enabled in JIRA. 
5. We do not use stages.
6. All User stories are estimated in Story Points 
   
   

Please let me know if you have any advises as we have more teams which are running in parallel and we would like to use this plugin for the planning for all teams. 

[Adrian Lazar]

What query did you use for your team boards?

[Jelena Kutlaca]

The queries are: 

project = Project_1 AND component = Component_1 ORDER BY Rank ASC

project in ("Project_1 ", "Project_2 ", "Project_3", "Project_4") AND (component in (Component_2, Component_3)) ORDER BY Rank ASC

[Attila Madarasz]

I am also very much looking forward to parallel sprint support.  

Our situation being that we have 4 concurrent boards all within the same JIRA project.  One of those is a trouble-ticket board (for non-critical tickets), the other three are independent sub-projects all contributing to the same JIRA project, each with a separate board.  There is indeed overlap with team members partaking in at least 2 boards concurrently (one for the trouble-ticket board and another for the sub-project board they're assigned to).

I found a workaround recently for our situation for now though.  I have created a single unified board that has a single sprint but with team based quick filters at the top of that unified board.  Each team can view their work queue as needed, and Portfolio then can do its job as I needed.

From an observers perspective, the problem from Portfolio's side is the current inability to physically display concurrent sprints in the gantt view.  Maybe it goes back to the import of the sprints themselves ? .. but it's understandable that a dilemma exists trying to display concurrent sprint titles under a single JIRA project .. there's just no allowance for it in the layout, it seems.

[Rhys Christian]

Please see my new answer for an implementation update and a new workaround guide.
Feel free to add your feedback.

Cheers,