You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
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.
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.
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.
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)
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.
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.
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:
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)
(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.
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.
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?
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
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.
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!!
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.
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.