Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Advanced Roadmaps - Option to "Use sprint dates when issues don't have start and end dates"

I am curious how people are using the "Use sprint dates when issues don't have start and end dates" feature in Advanced Roadmaps

It seems quite useful.  However:

We would prefer, when a Story begins, to track its Actual Start Date and then have Advanced Roadmaps calculate its end date (based upon sprint dates).  But it appears like both the "start date" and "end date" must be empty for this automatic calculation. 

Anyone know why?

Let's give an example.  Imagine I had a "Story" that began in Sprint 1, but wasn't finished.  Now it's in Sprint 2.

If I leave the dates empty, Advanced Roadmaps will show this "Story" starting with Start/End dates from Sprint 2.  Which is not accurate.

However, if I populate the Start Date (with its actual Start Date), then Advanced Roadmaps leaves the End Date unset (even though it could inherit the End Date from the end date of Sprint 2).

I am curious what people actually do for these dates.  As a note, we have no intention of anyone changing the dates in Advanced Roadmaps itself.  As that will generate other issues (based upon the way we currently use Jira).


Doug Levitt

Agile Coach

1 answer

0 votes
Dave Atlassian Team Mar 29, 2021

Hi @Doug Levitt,

The behaviour isn't exactly as you've described as you've not included the impact of the issue state. If an issue is in Sprint 1 and moved to an In Progress status but is not resolved before the sprint is completed then the dates shown on the roadmap will span all sprints until the issue is resolved.

See this example screenshot:

Screen Shot 2021-03-30 at 3.53.34 pm.pngHere you can see that "Issue1" spans both "IC Sprint 1" and "IC Sprint 2" because it has been started but not finished.

In your example, if you didn't actually start working on the issue in Sprint 1, why would you want the start date to indicate that you worked on it in Sprint 1? If you have started work on the issue then the expectation is that it would be moved to an in-progress state and then the dates would be reflected to incorporate that sprint.

At the moment we expect users to either plan based on sprint assignment or with dates (for each issue) but not both and I believe this is the first time I've heard any request for this to change.

Typically I just use sprint assignment (combined with roll-up dates) to generate the roadmap for my team but I do occasionally set a specific start or end date when something needs to be started or finished at a specific time.

There is a school of thought that agile teams should really only be planning to the granularity of sprints, but we recognise that this won't necessarily meet everyone's needs (and wouldn't be possible with Kanban teams).

Dates based on sprint assignment also work well with how teams might move issues on a backlog - this means that dates can be inferred independently of the planning team.

At the moment there are no plans to combine sprint dates and date field settings with how an issue is rendered on the timeline. The only exception to this is if you change the plan configuration so that "Due Date" is not used as the end date of the issue. In this case "Due Date" can be used as a deadline and a warning will be shown if the sprint assignment indicates scheduling beyond that date.



@Dave - Thanks for the reply.  I now better understand how you were envisioning that the tool would be used.

One of the things I was trying to do was display the Actual Start Date on the timeline.  As an example, say the Sprint started on Mar 1 and ended on March 15.  And Story #1 began on Mar 8, I want hoping to depict that (on the timeline).  I can partially do that (by setting a Start Date using Automation, when Story #1 moves into "In Progress").  However, Adv Roadmaps won't infer that the "worst case" End Date is March 15.  I guess I can use Automation to set that as well, but it's a bit of a pain (because there are a bunch of corner cases to account for).

So, maybe I need to "punt" on having an "exact" Start Date (the Start of Sprint is not that granular, particularly on a 2 week Sprint).



Like Dave likes this
Dave Atlassian Team Mar 30, 2021

@Doug Levitt- by actual start date are you looking to see the date that an issue change state from a To Do status to an In Progress state? If so would you want to display this to compare against the planned start and end date (which might be set via field or sprint).

I've always thought that it would be useful to compare transition dates (I when issues were actually started and finished) with the dates that they were planned to so that you can modify your plans based on current progress (and also see how well your plans track against reality) but I'm not sure if this is quite the use case you're describing?

My concern over mix-and-matching actual and planned data for the same visualisation is that it might be hard to distinguish which is which.

I'm really interested to understand the use case here because it sounds like the difference between using Advanced Roadmaps for planning as opposed for reporting? However I could be completely misunderstanding the requirement here and am very happy to be corrected if so!



Hi @Dave ,

I suppose I was thinking of MS Project (which i haven't used for ~ 10 years), where there is a planned start/end date and there is an indicator when the item actually started and ended.

Example: (see picture).

To my understanding, in Advanced Roadmaps, there is no "true" planned start/end date.  Rather, Advanced Roadmaps is inferring those dates from the Sprint Start/End Dates.  But that's not the Planned Start/Planned End Date.  That, actually, is: Earliest Possible Start Date or Latest Possible End Date.  And, we don't depict what the Actual is.  We need to use the Status to know if something started or if its Done.  That works (I suppose).  It would be more useful though, if we could display more fields AND the timeline could scroll.  Maybe the timeline can scroll, but I hadn't figured out how to do that.  As I want to display about 6 fields PLUS the timeline.

In any event, I think I understand how you envisioned it would work.  It would be great to have some comprehensive use cases describing how real software teams are using this.  I am particularly interested in how its being used where teams own the planning, but organizations want to use Adv Roadmaps to simply identify planning gaps (and if gaps exist, the users update how PBIs are assigned to Releases and Sprints).  Also, it would be helpful if you could eliminate the 5000 issue limit.  With 25+ Teams, we are nearing it (and have to eliminate SubTasks to make it work).

Thanks for listening and providing your feedback.


Like Joseph Leiba likes this

@Dave Dates comprise many of the biggest issues with Advanced Roadmaps.  For users who have a full understanding of the tool, these are likely non-issues.  However, its been my experience that many do not understand how date inferral works in Advanced Roadmaps, and the documentation, while extremely detailed, does not covey understanding - for a tool that provides such a high-level view of the data, that level of information is ironically missing from the documentation.  

There are guides, sure, and those work when everything is absolutely perfect.  But more so, those guides ALWAYS assume people are estimating in story points.

There need to be troubleshooting guides - deep, detailed guides on what to look for when things are off.  When there are dates that are added to issues because of external factors, such as sprint dates, there need to be indicators and tooltips.  There need to be ways to isolate these issues, so they can be examined separately.

Please see

@Dave  regarding your comment "it sounds like the difference between using Advanced Roadmaps for planning as opposed for reporting" I'm curious as to why  Advanced Roadmaps shouldn't be the go-to for both planning AND reporting?  What's the point of a plan if it can't be used for reporting?  I understand scenarios represent what if's but apart from that, plans can change at any time, with any tool, but reports always need to be made.

Suggest an answer

Log in or Sign up to answer
Site Admin
Community showcase
Published in Jira Software

Upcoming changes to epic fields in company-managed projects

👋 Hi there Jira Community! A few months ago we shared with you plans around renaming epics in your company-managed projects. As part of these changes, we highlighted upcoming changes to epics on...

1,495 views 11 22
Read article

Community Events

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

Events near you