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
If you already heard about Smart Commits in Bitbucket, know that you just stumbled upon something even better (and smarter!): Genius Commits by Better DevOps Automation for Jira Data Center (+ Server...
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