Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


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

Sprint dates appear different between jira and advanced roadmaps



I am seeing a discrepancy between my sprint dates in jira and the same sprint dates in advanced roadmaps.


I have a sprint planned in jira with this time frame:

07/Jan/21 4:10 AM - 13/Jan/21 8:10 PM

Within advanced roadmaps the same sprint has the following date range:

07/Jan - 12/Jan


Please can someone explain why AR hasn't used the 13th Jan for the last day? The issue is happening across all my projects.





2 answers

1 accepted

0 votes
Answer accepted
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Jan 10, 2021

Hi @Anisha Gallagher ,

We made the decision to show sprints like this for a few reasons, whilst it's not necessarily an ideal situation we felt like it was a good compromise - however, your feedback on our decision and the rationale would be useful.

We made a decision that all issues should be shown as starting at the beginning of the day (i.e. 00:00:00:000) and ending at the end of the day (i.e. 23:59:59:999) in order that issue bars are all aligned.

This also means that an issue started and stopped on the same day would always show as having a length of 1 day rather than potentially 0 days (this is also useful because it means that there is a visible bar to work with).

We also wanted to have the start and end of sprints align with the start and end dates of issue bars. 

Although it is possible to set precision on the start and end dates of a sprint (as you have described) we knew that if we adhered to that precision then the start of an issue wouldn't line up with the start of a sprint and might at best be aesthetically displeasing and at worst confusing.

However, if we took the same approach with sprints as we had with issues (i.e. that they start at the beginning of the day and finish at the end of the day) then we were concerned that this would cause the sprints to overlap.

We assumed that in a lot of cases a sprint might finish on the same day as the following sprint starts (for example, we finish our sprints at midday on a Tuesday and start the following sprint in the afternoon) - this allows us to have our retrospective in the morning and planning afterwards (it also means that we don't lose the ability to work on a weekend - whilst not encouraged, this provided flexibility for people who need to do this).

So that then creates a problem of overlapping sprints. Advanced Roadmaps does actually support this but it means that group headings (when grouping by team or sprint to show sprints on the timeline) are doubled - and we know that vertical real estate is something that we want to use efficiently in order to show as many issues on the screen at once as possible.

It would also be unusual to show Sprint 1 ending after Sprint 2 has started - we were also concerned this might be confusing.

Therefore taking all of the above into consideration we decided that by setting a sprint to end at the end of the previous day this would make the most sense when looking at issues in a plan. However, there are obvious limitations if you're setting dates directly on issues.

I hope that explanation at least makes sense, even if you don't agree with the decision we took.



I get the answer and it seems like a reasonable design choice. However, I can't see this documented in the Jira Cloud AR documentation and it's the first question my users asked of me.

I did see an article for the Server version which mentioned time zone issues in a round-about way.

Correct me if I'm wrong and you can point me to the page! Otherwise, can Atlassian please update the design documentation.

Like Charlie Crighton likes this

Hi @Dave

Thanks for your detailed explanation. I can see that you were trying to make the best decision. (Our sprints also end and start on the same day and our team works from different time zones.)

I wanted to add my feedback to let you know what this decision actually means for me:

  • Using Advanced Roadmaps is quite confusing for me because of this. It means that all issues that have the due date set to the last day of the sprint look like they actually end on the first day of the next sprint. (It took me quite a while of moving them back and forth until I realized what caused the problem. Might be good to mention it in the webinar.)
  • I have an issue that takes only 1 day and is planned for the last day of the sprint. Now I get a warning because it's outside of the assigned sprint. Of course, I know it's not actually wrong but I'd like to solve all warnings. Also, other team members might not know about this behaviour and think we have a problem.

Do you have any plans to improve this any time soon? Or is it something we just have to live with? If that's the case we might not want to use Advanced Roadmaps to not confuse our team members.

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events