When I joined Atlassian in 2004, the release cycle was 90 days. That number held for years. Then we accelerated. First with Stash (now Bitbucket Server) down to five weeks, then with Cloud to days, sometimes hours.

From an engineering perspective, that acceleration was pretty exciting. Faster feedback. Fewer months between shipping something and learning whether it worked. And for customers, there are real benefits to getting improvements quickly rather than waiting for a quarterly drop.

But there are drawbacks too, and I don't think they get talked about enough.

Keeping up with a tool that changes constantly is its own kind of work. A new navigation bar here, renamed buttons there, a reworked view that makes your entire internal training guide incorrect overnight. And somewhere in the Atlassian Community, the familiar refrain: "Did something just change? Where did [thing] go?"

Atlassian has heard it. Starting at Team '26 (May 5–7 in Anaheim), they're moving to a seasonal release model. Three bundled releases per year, each tied to a predictable window. I think this is good news… and I want to explain why. And what it means practically for product teams.

Too much change

The SaaS default has been to ship as fast as possible. Fast feedback loops, continuous iteration, always-on deployment. For a lot of products that's the right model.

The trouble is, it works better when your tool sits at the edge of someone's workflow. When it's the center, when hundreds of people depend on Jira daily, every update carries a real change management cost. Admins have to re-document, users relearn, support queues tick up, and training materials go stale.

Multiply that across fifty-odd updates a year and you're paying a tax that nobody agreed to when they signed up.

Atlassian's move to seasonal releases is an acknowledgement of that reality. Continuous change, at Jira's scale, was creating more friction than the updates were resolving.

What this changes for admins and product teams

The immediate win is predictability. Three release windows per year, each with advance notice and a preview period, means the update becomes an event you can plan around — a short brief to your team, an updated internal guide, a Loom walkthrough if that's your style. The change management work is the same; you just get to choose when you do it, instead of discovering the change mid-morning when someone messages asking why the sidebar looks different.

There's also an implication for stakeholder communication. Product teams that maintain roadmaps or portals accessible to non-technical stakeholders have always had to decide how to communicate tool changes to people who aren't in Jira every day. Seasonal bundling makes that easier. One heads-up, timed well, instead of twelve minor updates that mostly go unread.

What to watch at Team '26

AI agents are the main event. Atlassian opened the agents beta in February. You can now assign tickets to an AI agent the same way you'd assign them to a person. And the May release is expected to deepen that integration. If you haven't looked at what agents can do for triage, prioritisation, or discovery work, Team '26 is the right moment to start.

Navigation is also worth watching. Atlassian has been gradually reworking the Jira sidebar and project navigation, and seasonal bundling gives them a cleaner window for bigger UI changes. There are enough community threads on this to suggest something meaningful is planned.

JPD changes are harder to predict, but Atlassian's investment in idea hierarchies and the connection between discovery and delivery has been consistent. Any movement there will matter if your team lives in JPD.

Before May 5

Check the preview changelog when it drops. Once you know what's changing, write two paragraphs for your team — what's moving, what it affects, when it goes live. Seasonal releases only reduce friction if you actually use the notice period.