[Help Needed] Jira Stopped Automatically Populating My Sprint Start Dates and Durations

[Gino Scozzari]

Hi Jira Team and Community Members, 

I'm hoping there's an expert out there that can help me with my issue. I've done my best to provide as much detail as possible, but please ask clarifying questions if needed - any support is greatly appreciated! 

----------

High-level Problem Description: I have an issue where Jira has stopped automatically populating my newly created sprint start dates based on the previously created sprint's end date and has stopped automatically populating/defaulting my sprint duration to 2-weeks. 

My Jira Setup Context and Sprint Process: 

• I am using Jira Cloud on a standard plan
• I have a Scrum project setup using sprints 
• Our typical sprint durations are 2-weeks
• I have 3 codependent sprint teams using 3 separate board views in the same project running 3 separate parallel sprints (parallel sprints is turned on)
• In addition to my active sprints, I create 2 additional "on-deck" future sprints for each team
  • The first on-deck sprint is left empty for the active sprint's carryover
  • The second on-deck sprint has groomed backlog pulled in to review during planning meetings

How the Problem Started:

• During the November and December holiday season, my team moves from 2-week sprints to 4-week sprints to accommodate PTO schedules and somewhat normalize velocity. We move back to standard 2-week sprints after the holiday season.
• After closing the previous sprints for each team, I went into each sprint team's board and updated the soon to be active (being planned) sprint duration from the hardcoded/predefined 2-week option to the hardcoded/predefined 4-week option.
  • After doing this, every new on-deck sprint that I create does not use the previously created sprint's end date as its start date and does not set the duration to two weeks - new sprints are simply being added as "custom" with no start or end dates.

My Research and Thoughts:

• From my research, I understand Jira manages automatically populating sprint cycle date and duration information with behind-the-scenes logic that looks at the previously created sprint's end date, with the overall default for new
  Scrum projects being 2-weeks.
• I read somewhere that Jira will only key off the active sprint, however, that was not the case. It was keying start dates off the last created on-deck sprint's end date, which is exactly how I wanted it to function seeing that I always have 2 future sprints created in advance.
• I assume that when I adjusted my consistent 2-week pattern for the first time, that the governing logic was removed because Jira is now seeing a hybrid pattern of both 2-week and 4-week sprints, and does not want to proactively make an assumption to keep adding newly created on-deck sprints with 2-week cycles. 

Questions and Help Needed:

1. Is this issue a temporary inconvenience until my teams get back on an active pattern of completing 2-week sprints, where Jira will recognize the pattern again and start auto-populating start dates and 2-week durations for newly created sprints?
2. Are there any steps I can take to force Jira to get back into a 2-week flow?
   
   • e.g. Only have my active sprint populated with no on-deck sprints once we get back into a 2-week cycle for the first 1-2 sprints and then start adding on-deck sprints again when the pattern is recognized ("fresh start").
3. If #1 and #2 are invalid or unknown, is there a way I can force newly created sprints to:
   
   1. Have a start date of the previously created sprint's end date
   2. Have a default duration of 2 weeks (I'd rather adjust this once or twice a year for the exceptions instead of every 2 weeks)

----------

Looking forward to any thoughts on how to tackle this going forward. Thanks! 

Best,
Gino

[Anthony Morais · Accepted solution]

Hi @Gino Scozzari 

This is expected Jira behavior.

Jira does not store a fixed sprint duration.
New sprint dates are auto-populated only when Jira detects a consistent pattern based on your last sprint’s end date + duration.

If a sprint is changed to a Custom duration (not 1/2/3/4 weeks), Jira stops carrying dates forward and new sprints will appear without dates.

When your team switched between 2-week and 4-week sprints, Jira no longer recognized a stable pattern, so it stopped auto-populating dates for new sprints.

How to restore the automatic behavior

Go back to using strict 2-week sprints for the next few cycles.

Create 1–2 future sprints manually with correct dates.

Jira typically “relearns” the cadence after 1–2 consistent iterations.

Fixed sprint duration cannot be enforced

Jira cannot lock sprint duration natively.
If strict control is needed, you can use automation reminders or a planning app like Advanced Roadmaps.

Hope this helps!

[Gino Scozzari]

Hi @Anthony Morais thank you very much for this reply - this is great info! 

I assumed what you mentioned was likely the case - there appeared to be some sort of automatic pattern recognition logic that is not exposed as explicit setting definition anywhere in the UI for users to be able to define a default sprint duration (e.g. two-weeks) as well as the start date criterion (e.g. use last created sprint's end date). 

I did open a customer support ticket, and the advice I have been initially given was to copy of all my boards to create new boards within the project once my team is ready to get back into a consistent 2-week cadence after the holidays.

The logic provided around this recommendation was that Jira WILL NOT relearn sprint cadence patterns again after a few completed consistent cycles, and that I would need to create new boards to reestablish the pattern again from a fresh "zero" baseline. I believe the support representative I spoke with was not 100% sure on this, so he escalated my ticket for further review and research. I obviously do not want to have to copy my existing boards as a routine solution.

I did also ask for an enhancement request to be logged to allow users to set default settings for sprint duration and start date for the future. Hopefully that receives some visibility/traction; I've seen other users run into this exact same problem with different context.

From your advice, once my team is back on 2-week sprint cycles, and we've completed 1-2 cycles with all proactively created "on-deck" future sprints that have been adjusted manually to be two-week cycles with start dates of the previous sprint's end date, Jira SHOULD recognize a repeating pattern again, and newly created on-deck sprints SHOULD automatically populate the duration and start date to follow that pattern - correct? 

Our team doesn't have a need at the moment for the core features of Advance Roadmaps, but I did see that users can control the sprint cadence more granularly with that addition.

Can you clarify what you mean by using automation reminders to help with sprint cadence control?

Thanks in advance!

[Anthony Morais]

Hi Gino,

Yes, you understood it correctly. Jira really depends on the pattern of previous sprints to automatically suggest the next dates. Since your team alternated between 2-week and 4-week cycles, it lost that reference, and this is expected. Once the team runs a few consecutive 2-week sprints again, Jira usually “relearns” the pattern. I’ve seen similar cases before and this is exactly what happened.

Regarding the automation reminders, what I meant was sending a notification at the end of each sprint so the team closes it on the correct date, or alerting someone when a sprint is created with an unexpected duration. This does not fix the dates automatically, but it helps prevent Jira from losing the cadence again.

[Gino Scozzari]

Thanks again for the follow-up @Anthony Morais 

Makes sense all around - I'll keep my "on-deck" sprint creation process in place with manual adjustments, and hopefully the pattern locks back in after a couple of completed two-week cycles next year. If I find the reminders useful, I'll toss those into the mix as well. 

Although not ideal, having an understanding of how automatic sprint cycle definition functions is very helpful. As a product person myself, relying on underlying recognition logic seems pretty wonky/unintuitive, so hopefully we see a future enhancement that allows teams to have explicit control over how this behaves.

- Gino