nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Jean-Pierre Froud_m3r5v6

Hi,

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

Quote:

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.

Comments

Dave

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.

Regards,

Dave

Jean-Pierre Froud_m3r5v6

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.

Lopes, Bonnie Q

@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.

Dave

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?

Regards,

Dave

Thanks for sharing this information @Lopes, Bonnie Q , 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?

Regards,

Dave

Lopes, Bonnie Q

@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

Jean-Pierre Froud_m3r5v6

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.

Tarang

So I understand the dodo elements of the the legacy interface, however the following hasn't been accounted for AFAIK with the so called Advanced Roadmap.

The new experience is primarily a view for traditional Project managers who look to own plans and "drive" these plans using gnatt charts. This is antithesis to how Agile teams work and how they develop and view their plans corresponding to Release planning and Roadmap plans.

The feature that is missing is in having a default or preference view for the Team, that is currently available by default in the Live plans. If one is using a Model View Controller approach to deliver the view then surely one can account for Agile team view and their ability to recalibrate the Roadmap by re-ordering the team backlog as well as the Project and Program Manager who needs a gnatt chart view.

This issue is critical if one is to get teams to embrace not just the sprint/iteration planning, short term planning, but also the need for over the horizon/ roadmap planning, long term planning/forecasting. As an agile coach I feel strongly about this as otherwise teams aren't going to embrace this level of planning and interaction using this tool. Which only creates the gap in reality between the Product Roadmap as envisioned by Product/Program/Project managers and the reality based on Team view and execution.

Tarang

Oh feedback aside, I just discovered that the new release of on-prem Jira sunset Live Plans such that teams that use Live Plans can continue working with them but if a new team is setup they can't use Live Plans. Rather than afford users the choice, even if it was unsupported feature, now they are forced to deal an interface that is valuable to project and program managers but not to the teams that are adopting agile practices.

Thank you Atlassian what a way to go!!

Jean-Pierre Froud_m3r5v6

We stuck to live plan until now. But our JIRA Admin will soon update to JIRA v9.3.1 where live plans don't exist anymore. (We tried to change his mind but we couldn't)

We tried switching to the "improved" interface but we lose almost all features.

"Auto-schedule" is slow, updates items (and thus item history) while "calculate" is fast and doesn't change anything in items fields
Calculated plan is false if you estimate an epic which contains estimated story, we have to remove all estimations from epics and create a child story holding the epic estimation...
We have to create ALL sprints of a release to be able to manually modify each sprint capacity, since projected sprints capacity isn't editable
No more original story points field (why!?) It's now harder to "box" an item's estimation and check if you're not spending too much on it
The "capacity view" was our must loved feature. Seeing a full release with no manual updates. Just input velocity, hours/week and holidays and everything was calculated in seconds.
We could answer in a single click to this question before: how many story points are planned for this release? Now we have to extract excels and sum pending stories.

This update is very confusing to me. I've experience only once a similar case when spotify removed a top feature with almost no explanation https://community.spotify.com/t5/Content-Questions/Retirement-of-our-Running-Feature/td-p/4383603

Why can't you just keep live plans, there's almost nothing we can use in the new version.

Are-there other tools/plugins we can switch to lookiing like live plan?

I hope this discussion will pop into an Atlassian team member.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

advanced-roadmaps

feedback