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
We are trying to use the Jira Advanced Roadmaps (Plan) to track multiple projects and to identify critical path items.
We can't see how to do this.
Posted in here some time ago - FYI i have found the solution - we will be disabling the Software Premium feature in favour of moving to BigPicture, more functionality and an improved financial footprint. Atlassian, you have shot yourselves in the foot with a pricing and features model that is incoherant and isn't proving value to your customers.
I also completely agree with @Melissa.Stockbridge. This is absolutely essential for a roadmap tool if used for projects which have always a defined end date which need to be ensured and tracked. As it is further required by ASPICE to know the critical path in a project, it prevents us from using advanced roadmap (and the fact, that it can´t show milestones in a very useful way).
I agree as well with the Critical Path issue. We have many projects using Jira Advanced Roadmaps and this is the main factor that is missing and pushing the teams to use another tool instead. If there is a way we can get this sooner than later that would be great and help get our projects using one tool instead of multiple.
It is obvious from the responses from Dave that he does not understand what Critical path is. It alos an important legal and contractual document. It is alos obvious that many customers need it and I am surpised it is not to be addedd to thw tools or that some interface with other professional tools such as Oracel Primavera or Asta PowerProject
Hi @Tracy Moffat ,
When you create a plan you can bring in multiple projects into it as issue sources. You should make sure that you've configured the relationships that you want to use to define the critical path in the global dependencies configuration (from the top navigation bar use "Plans" -> "Settings" -> "Advanced Roadmaps Dependencies").
By default only the "blocks" / "is blocked by" relationship is considered a dependency but you can change this as required (multiple relationship types can be considered a dependency).
I would then recommend that you use the "Dependencies" filter from the plan and choose a specific issue that you know is on the critical path and make sure you check the box marked "Include dependency path" (see screenshot)
This will filter the plan to just show issues that are flowing through that issue. This should allow you to understand the critical path and make sure that all of the issues in it are scheduled appropriately.
If you are just interested in understanding the relationship between issues (and aren't so concerned about when they are scheduled) then you can use the "Dependencies Report" tab and also filter for an issue on the critical path. You can then use this to group or roll up to team to understand where inter-team dependencies might be that require the work to get done.
I hope this helps answer the question, please let me know if I've misunderstood the requirement or I need to provide any additional clarifications.
So, there really is no way to automatically identify the full critical path using this tool. Users have to go one by one looking at each set of dependencies and manually sort it out and then use the tool.
I've also reviewed some auto-scheduling documentation and it appears that with the newer planning tool that resources and earliest start dates are no longer being considered in auto-scheduling: https://confluence.atlassian.com/advancedroadmapsserver/auto-scheduling-issues-967895245.html
What was the reason for excluding these key items?
Hi @Tracy Moffat ,
To answer the last question first... we removed some of the capabilities from the tool when we developed the new interface (originally as Portfolio 3.0 on Server) because we were finding that the complexity of the tool as causing confusing. Whilst the features were powerful and some customers were getting a lot of value from them this wasn't true for all customers. We had a goal to simplify the interface and ensure that attributes assigned to issues in a plan were also visible in the issue details screens throughout the rest of Jira. We also wanted to remove the reliance on the scheduling algorithm for building a roadmap (as this required a lot of information to be defined to get useful output). Making decisions like this is always tricky because it is always likely to be unpopular with some customers - however, the changes were very successful and resulted in us bringing those changes to the Cloud platform and we have seen rapid adoption of the new interface and dramatic reduction in usage of the Live Plans interface. So whilst we acknowledge that some customers still value the capabilities you mention we currently have no immediate plans to reintroduce them.
It would be interesting to understand how you would want the critical path to be automatically identified. I can't see a way of defining this without creating dependencies between issues to actually build the path... but visualising with the tool should be relatively straightforward using the dependency filtering methods I described (on both the Roadmap and Dependency Report tabs). I'd be really keen to learn how you'd like this to be improved and to understand what we would need to add to improve the situation.
Need the tool to highlight all issues (in a different color - typically RED is standard) that are on the critical path - meaning those activities that push the timeline to the longest path - start to finish.
This tells someone who can read it that if any of those RED issues on the critical path go south the final completion date will be pushed out based on the dependencies set between them.
I can understand why you pulled it out as it's not something most people would care about in a task check off tool. But when you're looking at whole schedules at the enterprise level with hundreds of dependencies and issues it matters a whole lot. It also helps us program managers understand what needs attention as it slips - because the algorithm should be constantly checking for changes and other issues would wind up on the critical path as the time slips.
Thanks @Melissa.Stockbridge - this is a really interesting suggestion, but there's a few things that might be worth considering here...
What you're describing makes sense when an Advanced Roadmaps plan represents an actual "plan" (in the sense that it only contains issues that need to be done it achieve a defined objective). In this case the scope of a plan is fixed (i.e. no more issues will get added to it as they are created in the issue sources).
I know that some customers use Advanced Roadmaps in this way but typically it's more common for plans to be more open ended. Plans are sourced from projects and boards that are continuously added to - the plan never "ends".
The reason why this distinction is important is because I'm wondering how easy it would be to identify the critical path. In a fixed-scope plan you can identify the critical path as the issues in a dependency chain that have the earliest start and latest end dates (I think? I could be wrong here).
But with a more open-ended plan you could have multiple dependency chains that might be critical paths to different objectives (a release maybe?). Would you want to show multiple critical paths?
Hopefully that makes sense - I'm just trying to understand if your proposal is constrained to a specific use case.
Hi @Dave - in my world there is no open ended project, there is only one schedule with a finish date and everyone abides by it or we get into trouble.
In my experience there are 2 generally accepted ways for calculating Critical Path - Longest Path OR Issues where Total Float = 0. A preference setting for the end user could allow the user to set which method of calculation they prefer. It is true there could be multiple critical float paths especially when a plan is small, however, in larger plans the likelihood of multiple critical paths is lessened and I would argue that any plan with more than ~50% of issues on the critical path is not a good plan whether it be with regard to durations/dependencies or sequencing.
I need a tool to help me show all tasks/issues that, if late, would impact the final date of the project as critical when they are on the "primary" or most critical path.
When you speak of multiple critical paths what I think you're getting at is the idea of multiple float paths - (sequences of issues) that affect the project schedule. Calculating multiple float paths should be a preference to allow the user to perform but it's likely most people would not use this.
If you want to use the Total Float Method, the tool should identify first which relationship has the most critical path based on dependencies and then use that task as a starting point. Then determine what dependent issues have the most critical relationship total float among all possible paths until you reach a task that has no relationships. The path that contains those activities is the MOST CRITICAL PATH which should always be shown as the critical path. If users do not use dependencies then it will not be calculated correctly. Those users will likely not care about that feature anyways.
Most enterprise tools that support multiple float paths allow the end user to select whether or not they want to even do that calculation but still calculates the primary critical path for them and then allows them to number the other sub-paths in order of their perceived criticality but keep them in the background to be turned on as a "layer" to perform comparisons.
The "Longest Path" is my preferred method and as part of your overall goal of improving date driven delivery for organizations, I can't see how this would not be a very important tool to project managers/product managers, scrum masters, program managers and anyone else out there that needs to make sure dates are met.
Thanks for your question! Melissa
Tangentially, to also to have dependencies push everything to the right when one issue misses its target (maybe as an alternate scenario.)
I support everything that @Marlene_Kilpatrick said above. I am a Project Management Office Director and have been delivering software solutions for 25 years. Critical Path features in the tool would be great and not having them prevents me and my project managers and other project stakeholders from using it.
I completely appreciate what you're saying here and I'm definitely not suggesting that the request isn't a valid one or that improving dependency handling wouldn't be valuable. However, at the moment it's not a priority for us to address this in the short to medium term based on the broader needs of the platform and customers. Obviously we don't want to hear that any customer is unable to use Advanced Roadmaps due to a feature gap but unfortunately we don't have the resources to address every requirement on demand and have to carefully evaluate the priorities of each item on our backlog.
It would be easy for me to make a false promise here, but I just want to make sure that your expectations area realistically set here - I don't expect to see any changes in the foreseeable future to address the critical path needs that you're describing.
Just getting out from a meeting where we have to create reports for corporate leadership. Guess what, they just requested a couple of additional information to be included in our reports and one of them is Critical Path. Don't know how to address that efficiently with Advanced Roadmaps (unless a do it "manually").
I would also add that a continously updating plan still needs a critical path. Simply as you add new activities the critical path is updated by the tool.
Moreover, any project has delivery dates where they have to produce something to put on the market. This surely is not just a request of companies like mine, that have a production line and hence a date against which they want to know ...whether they will be going in production and what activities they need to look out for that could compromise that date.
Thank you very much for your being honest Dave. Definitely Jira is becoming less interesting for me and my team, I cannot understand how you don´t care about the amount of work that Jira roadmap generate in some roles because of the lack of madurity that the tool offers. Really atonished. We have to go back to Microsoft project. So sad!!
I'm screaming into the echo chamber at this point, but... "Plus 100" on everything everyone of the Community has said about the necessity for, and the absolute crucial nature of, having a Critical Path feature built into Advanced Roadmaps. It's an absolute "miss," in my opinion, on the part of Atlassian to not see and understand the value of this feature to existing and potential customers. It's an absolute blind spot in the tool.