Dave Atlassian Team

Thanks for the update, Hans. If there are further problems please let us know. Regards, Dave

Thanks Paul, that's useful feedback. Your idea of copying plans is an interesting one which would allow you to create a template plan with a set of views (and might be an interim solution that we could look at). Would you not be concerned about the divergence of views after copying? Or is it just that you need them to get…

Hi Hans, Thanks for raising this question - this sounds like an unusual situation and if you have paid support (i.e. you're not on a free trial) then I'd recommend reaching out to your support representative to get some assistance here. However, there are a few things about your question that would be useful to clarify...…

Hi Paul, Thanks for the feedback. When we considered the view switching capabilities for Advanced Roadmaps we did think about these types of use cases and discussed the options for having a full ownership model for views as we recognised that there would be cases where you might want to create one view and share it between…

No worries @Leopold van Lynden - glad I was able to help!

Hi @Leopold van Lynden , I suspect the reason that this is happening is that you only have one board as an issue source for the plan and that all the sprints appear on that board? The way that I would recommend you set up your plans / boards would be as follows: * Create your plan * Create teams in the plan for each team…

Thanks @Alessa Jaeger _LSY_ - so just to confirm, you can see (and set) those "Planned Start" and "Planned End" fields in the issue screens for issues from all the projects that are loaded into the plan? Regards, Dave

Hi @Alessa Jaeger _LSY_ , I'm going to assume that these plans are configured with different issue sources and that for the plan with more options your issue sources include projects configured to use the listed custom fields, but for the plan with fewer options the projects configured don't have any date type custom…

Hi @Rob Horan , By default the "blocks / blocked by" relationship is used to define a dependency in Advanced Roadmaps but you can actually configure it to use any relationship type to be considered a dependency. From the "Plans" menu select "Settings" and then "Advanced Roadmaps Dependencies" from the sidebar menu on the…

One option would be to use a JQL filter as an issue source and then (at least on the Server version of Advanced Roadmaps) you can filter by issue source (look for "Issue source" in the filters menu). That would then provide you the view you're looking for. However, if you're looking to very quickly change the filter within…

Hi @Heather Barcomb , Thanks for the feedback on this... sadly it's not possible to achieve what you're asking for at the moment. When we created the design for this we wanted to find a way to clearly indicate issues that to not match the specified filter. The reason that this was important was that we still wanted to show…

Hi @Abbie Skelly , First I just wanted to confirm that you're using Advanced Roadmaps (and not just Roadmaps)... if you are using Advanced Roadmaps then our usual recommendation would be that you have 2 issue sources - one for each project. However, you could just have one for cross-project JQL filter as an issue source.…

No worries @Anisha Gallagher - this is great feedback that you've provided. We do recognise that the auto-scheduling results and the relationship between estimates and dates is not completely intuitive and it's definitely something we'd like to improve! Regards, Dave

Hi @Anisha Gallagher , We made the decision not to create too much tightly coupled behaviour between estimates and the dates on issues. The reason being is that even though an issue might be expected to be a days work that does not always necessarily equate to being a single day on the timeline (you might complete 8 hours…

Hi @Anisha Gallagher , Thanks for the clarification. The reason for this is that the auto-scheduler works at the granularity of a sprint (the dates assigned would be the expected start / end of the sprint). Where a sprint exists it will also assign the sprint. It sounds like the team in the plan is configured to have 2…

Hi @tyrone kimble , If all other things are truly equal (fix versions, status, etc) and the epics are both appearing on that Kanban board then you might want to double check your issue source configuration to make sure that you haven't accidentally excluded the epic from the plan. You seem to have examined the most likely…

Hi @Anisha Gallagher , Have you had the chance to read through the documentation on this at all yet? It will probably provide a better guide to how it works than an answer I write up myself - please have a read through here: https://confluence.atlassian.com/advancedroadmapscloud/auto-scheduling-issues-998651231.html…

Hi @Anisha Gallagher , Could I just confirm if you're using Roadmaps or Advanced Roadmaps? There is an auto-schedule capability in Advanced Roadmaps that will assign dates, sprints, releases and teams to your issues based on the estimates that you've provided. But this capability does not exist in Roadmaps. Advanced…

@marie.mogridge , @chris.reyes - We'd recommend that you reach out to https://support.atlassian.com/contact/ so that we can better look into these issues. It's likely to yield a faster resolution than via these community posts. Regards, Dave

If you mean in the hierarchy configuration itself, then sadly not. This is something of a historical remnant from the origins of Advanced Roadmaps (formerly Portfolio) and the way that epic were introduced into Jira. The relationship between story level and epic is fixed (and you can't actually move the default epic issue…

Hi @Julia Hunter , Unfortunately it is not possible as you cannot skip hierarchy levels (i.e. you cannot connect a story directly to an initiative). Your options are to either create an epic to "bridge" the stories or to just an epic and give it a smaller (although I appreciate that this comes with it's own problem as an…

Hi @Laura Gerlev Hansen, Unfortunately it's not possible to do this at the moment. There is also a caveat that you should be aware of that somewhat complicates this request. Changes are shown at the issue/release/team level and not at the attribute level. So if I change the dates of an issue and then you change the release…

@Lars Morten Nygaard We're in the process of rolling out the Export CSV feature at the moment. Feature rollout can take several weeks to reach all customers - but you should have this feature within a month (if you haven't already got it since writing this question!) Regards, Dave

Thanks @Jenn Sherman ... you're right that this shows how to group by component. Grouping by component and label is slightly different than the other groupings because multiple values can be assigned. In a lot of cases we found that users wanted to construct groups rather than having a separate group for each individual…

@Lars Morten Nygaard The estimate field in Advanced Roadmaps is linked to the remaining estimate in a Jira issue rather than the Original Estimate field. You can find this under "Time tracking" on the issue details view. We use Remaining Estimate so that when you plan future sprints and review progress on an issue you are…

Hi @Vivianne Eriksson , Thanks for reaching out about this. Out of interest are you using Server or Cloud ? We launched this as an early access feature for Server earlier in the year and have just started rolling it out to Cloud with some minor improvements (which will come to Server in due course). We do want to continue…

@Sowa @Rick Olson When we release a feature to Cloud we actually roll it out over a period of time to our customers - we don't release to all customers at once (this is done so that we can monitor the roll-out to be sure that is not introducing any unforeseen problems). At the time of writing, we are still in the process…

Sorry for the slow response @Joseph Chung Yin - I was not previously aware of this issue - it looks like this has been raised as this bug: https://jira.atlassian.com/browse/JPOSERVER-2871 - I'll aim to get this on our short term roadmap to be fixed.

This is correct - each hierarchy level has its own name, but you can rename the hierarchy level from "Story" to something else if you'd prefer. You do this from the hierarchy configuration page:

Hi @Berry Kersten , At the moment this isn't possible. The reason for this is that an issue can appear in multiple plans and each plan can have a different configured iteration length for the associated team. Therefore it's not possible to reliably set this data automatically. I totally acknowledge that this is very…