Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Feedback on: Future of Advanced Roadmaps: Ending support for Live plans


We got an email announcing the end of support for Live plans (legacy interface).


We recognize that for some this will be a major change. Live plans users are urged to reach out to let us know their challenges. Over the coming months we'll be working to address them.

That's what I'm doing by starting this discussion.

The problem we have with the new interface:

However, some team management aspects of the legacy interface have gone the way of the dodo. In the improved interface, you won’t find working hours and days, skills/stages, individual absences, and virtual team members.

We currently use these features and rely on them to plan our releases (all but the skill/stages). This is not only an interface change, we're talking of feature loss and this is why we stuck with "legacy interface" waiting for these features to be continued on the new interface.


Dave Atlassian Team Mar 02, 2021

Hi @Jean-Pierre Froud ,

Thanks for starting this discussion. I’d be particularly keen to understand how you are using the features of Live Plans that you mentioned - ideally through the lens of the problem that you’re trying to solve. For example how are you currently using virtual users? What particular problem is that solving?

I’m particularly interested to understand more about how you’re using the individual team member configurations (absences, exceptions, working hours and days, etc) - but also more generally about how you use teams. We’re keen to reintroduce individual capacity management capabilities but not necessarily replicating the features of Live Plans exactly as they are. For example, we know that some people use the weekly hours settings to “hack” an individuals contribution to a team (particularly when an individual contributes to more than one team) and we would rather address this requirement more transparently. We know from our data analysis that weekly hours is twice as likely to be used as absences and four times as likely to be used as exceptions - but we’re keen to add add qualitative understanding of that quantitive data.

More broadly we’re also interested in understanding how customers use (and more importantly how they’d like to use) teams across plans (i.e. private versus shared teams) and how people feel about attributes of shared teams being scoped to the the plan rather than also being shared. We’d like to understand if the individual and team capacity capabilities in Live Plans were completely meeting your needs or if there are gaps or improvements that could have been made?

We're really keen to understand the needs of our customers so that we can address them in the new interface - anything that people would like to share on these topics would be incredibly valuable.



Hi @Dave 

We have 3 fixed date releases per year. Thus we're interesting in tracking team capacity and forecast the scope we can deliver in each release. He also have legal requirements at each release, we must implement law changes.

How we use virtual users:

We use this feature maybe once a year when we know a team is going to need to grow to deliver "must" stories. We add some virtual members, set their team availability dates and increase velocity. At the end we use the new calculated capacity as a forecast and experiment with scenarios if needed.

How we use team member configuration (absences, weekly hours...) 

We use this in a daily basis. We do use the weekly hours as you described, reflecting individual contribution. Not because some people contribute to more than one team, rather because some people have more experience and their absence is going to decrease team capacity more than a newly arrived junior.

We tried using the skill features and phases at the beginning to reflect that but we abandoned because it was too complicated and the weekly hours a much simpler alternative.

We also use the "schedule" view combined with grouping by team members to  know when each member will be absent during the sprint/release/year. (some sort of team calendar)

Team scope

For now each team is dedicated to a single plan. Even though we configured the teams to be shared, we don't really use that and a private team will also do I guess. I must admit I didn't really understand the difference and use cases of private vs shared teams.

Other feedback

The capacity view on live plans is also something we lack in the new interface. Projected sprints (sprints not created in Jira) in the new interface have much less information (almost none) than sprints in the capacity view of live plans. 

And we also find it easier to track overbooked releases in live plans.

Like Dave likes this
Dave Atlassian Team Mar 04, 2021

Thanks for sharing this information @Jean-Pierre Froud - it's incredibly helpful. 

It's interesting that you've gone for a team per plan approach... does that mean that individuals only contribute to one team? I'm also interested in if multiple teams work on the same Project? One of the reasons you might want to share a team is so that it can be queried using JQL and then you could use that to create boards for each team within a project.

With respect to capacity view it would be interesting to know if you've tried grouping by team or sprint to access the capacity bars for each sprint? I appreciate that this is a less detailed view than in Live Plans but it should give a good indication of team capacity.

Your virtual team member use case is also interesting is what we expect to be the most common use case (i.e. planning for future recruitment). 

I really appreciate you sharing this information. We do want to address the most common use cases that our customers have with respect to capacity planning so understanding how people are using the Live Plans features in incredibly helpful.

It's interesting your observation about setting individual contribution ... I think there is a natural inclination to not suggest that one person contributes more than another, however as you suggest not everyone is necessarily equal (i.e. juniors vs seniors) and not everyone might be able to contribute the same amount regardless of ability. In your opinion would you be comfortable setting contribution more directly rather than using the working hours approach?



Here are more details on our use:

There are 3 teams. Each team has a Scrum board in Jira built from a filter on Jira projects:

  • Team A has a scrum board with issues from Project 1, Project 2
  • Team B has a scrum board with issues from Project 3, Project 4, Project 5
  • Team C has a scrum board with issues from Project 6, Project 7

And there is a Plan for each team based on their board.

A person only contributes to 1 team. Sometimes, 2 teams need to work on the same projects but we couldn't find how to best reflect that on Jira, I'm interested in recommendations on how to do that using Jira and Advanced roadmap. Like I said, I couldn't find documentation on what would be the best approach for a setup like ours on how to best reflect multiple teams working on same project.

We tried adding on team B sprints, issues from team A board but we couldn't close Team A's current sprint because of that.

This sounds like a bad idea: (we didn't try it)

  • Team A has a scrum board with issues from Project 1, Project 2, Project 3
  • Team B has a scrum board with issues from Project 3, Project 4, Project 5

(2 Teams need to work on project 3 together)

In your opinion would you be comfortable setting contribution more directly rather than using the working hours approach?

Yes and I'm expressing the whole team view on that.

Like Dave likes this

@Dave ,

We wanted to use shared teams, so that we could take advantage of everything Advanced Roadmaps and teams offers for planning and scheduling, but the current constraint on this field, that prevents adding a context has forced us to abandon the use of Team.

We have 100's of teams and we provide a team dropdown on a Jira project basis, so only those teams participating on a single Jira Project show up.  We have anywhere from 3-8 teams participating on any given Jira project.  We could not have a single dropdown with 200+ entries (all the teams in Jira), as noone would be able to find their team to select in such a dropdown, hence why we create a context around team and this allows for our dropdown to be no more than 8 entries which is much more useable.

I would LOVE for you to consider allowing "context" (Specify teams to on a project by project basis) to be added to the TEAM field that is created in Jira for shared teams, so that we could remove our redundant field and take advantage of Teams in Advanced Roadmaps. 

Like Dave likes this
Dave Atlassian Team Mar 04, 2021

Thanks for sharing this information @Bonnie Lopes , I'm sorry to hear that you've not been able to take advantage of the Advanced Roadmaps team field.

Is the problem specifically within the Jira issue screens where the field will display all shared fields? Within a plan I believe that only teams imported into or scoped to the plan will be displayed as options

Would your preference be to actually constrain the teams that can be assigned to issues within a project? i.e. creating a direct association between teams and projects?



@Dave ,

Thank you for your response.  Yes it is only within Jira issue screens, which is where 99% of our people work, and enter new issues where teams need to be assigned to issue for them to show up on the proper board.  As all our board filters are written as Project =... and "Scrum Team" (wanting it to be Team) = ... Order by Rank ASC.

Yes, you are exactly right.  Looking to constrain what teams can be assign to issues within a project through the creation of direct associations between teams and projects.

We typically have between 4-8 teams participating on each project

Like Dave likes this


Log in or Sign up to comment
Community showcase
Published in Jira

⏰ Day in the life of a Jira Admin!

Hello Community! We thoroughly enjoyed this just-for-fun conversation in the Jira Admin Group about what it's like to be a Jira Admin. For #JiraJuly, our talented designers created these graphics t...

212 views 2 15
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you