Did Atlassian Just Admit the Pace Is the Problem?

Ask anyone running Jira in 2026 what’s wrong with Atlassian right now, and the answer isn’t any single feature or strategic direction. It’s the pace of updates. Releases land constantly, announced thinly or not at all, and admins are expected to absorb each one on arrival. I said as much back in June: “The honest answer to why admins miss things isn’t attention. It’s that keeping up with Atlassian changes is near impossible.” The problem isn’t any single change. It’s that nobody can keep up with the rate of change.

For creators it’s worse. An admin finds out a change broke something and has time to adjust a process. We creators tend to find out mid-demo, on camera, that the field we built a tutorial around got replaced overnight, or the button we’re pointing at moved three menus over. There’s no announcement to plan around. There’s just a screen that doesn’t match the script. If it’s a livestream, the only real fix is getting good at improvisation. If it’s recorded, the fix isn’t a quick edit. It’s a reshoot, and reshoots cost time and money that not everyone has. That gap between recording and publishing is long enough that a walkthrough can go wrong before it ever airs. I haven’t hit that on a blog post yet (knock on wood) but I also don’t do my own video content, so the risk sits differently for me than it does for my friends who do. That’s not a complaint about any single feature. It’s a complaint about being handed a moving target with no notice that it moved.

There’s a third group absorbing this the same way, and Gregory Van Hoof, an Atlassian Certified Consultant, named the problem directly in a comment on my certifications post a few weeks back: “With Atlassian rolling out changes so frequently, hands-on experience in a sandbox — solving real customer problems — delivers far more value [than certifications].” (You can read his full comment here.) That’s not a complaint about content going stale. It’s a rational calculation, and I don’t have a clean answer to it. I’m still mid-sweep on my own certification list, and comments like his are exactly the counterargument I haven’t resolved.

So that is why when I got an otherwise ordinary email from Atlassian on July 27 (one of yet another of the flood, to be sure), it really made me pause and go, “Oh….that’s different.” And exactly what made it different and what it could be signalling inside big “A” I think is worth discussing.

What landed on July 27

What had me so excited then? It was a batch of Jira announcements, all carrying the same July 27 date, all bundled into a single email under one subject line. That is not the trickle I just described, and it is not an accident either. What arrived in my inbox was the Jira 2026 Summer Release, the second installment of a seasonal release program Atlassian started this year for exactly this reason. Major user-facing features now land in three seasonal releases a year, with smaller bundles in between, and two of the three timed to Team and Team Europe. Spring 2026 was the first, and it brought agents in Jira, the For You page, guest access, and a set of admin controls. Summer is rolling out now and reaches general availability for all Jira Cloud customers by the end of August. A preview of the Fall release is already promised.

What got me was not the contents. A dozen good features is a Tuesday at Atlassian, and I can read release notes. What got me was the shape of the thing. Somebody had decided that handing us changes one at a time was not working, and had done something about it. That is an admission, albeit a quiet one, and the first I can remember seeing in some time. For years the answer to “how am I supposed to keep up with this” has been silence, or a link to a changelog I have to add to the mountain I already have to read and digest. This was different, because it implied the question had finally been asked inside the building.

That being said, I very much can be choosing to read too much into this. But, that is also the assumption the rest of this post rests on, and I should say so plainly. I am taking it as given that Atlassian wants admins to be able to keep up. If that is the goal, everything below is a description of the distance still to cover. If it is not the goal, I would like to know, because it changes what the rest of us should be asking for.

Fourteen announcements carry that July 27 date on Atlassian’s launch notes. My email did not include all of them, and Field Schemes was one of the ones left out. Whatever sorted that list, it was not sorting by how much a change would land on an admin.

The problem, in numbers

I wanted to know how bad the pace actually is rather than how bad it feels, so I went looking for a number I could defend. It turns out Atlassian keeps one. In Atlassian Administration, under Apps, then Release management, there is a page called App updates, and it lists every release note that affects your instance. On the morning of August 5 mine held 1,010 entries across all products, 489 of them Jira.

So I went through the whole thing.

Five hundred and ten of those started rolling out in 2026. August 5 is the 217th day of the year, which works out to 155 business days, so that is 3.3 changes every working day. Jira accounts for 194 on its own, or 1.25 a day. Confluence is not far behind at 176, or 1.14. If you run both, and most of us do, something moved under you roughly every three and a half working hours this year.

That 510 is a floor rather than a total. It leaves out 385 entries carrying no rollout date at all, and it comes from a Free tier organization, which sees a shorter list than the Enterprise instances most of you administer. Both of those push the real number up, not down.

That undated group deserves a paragraph, and it deserves a fair reading first. Two hundred and sixteen of them are changes that already finished rolling out, and if Atlassian only started filling in the schedule field partway through, going back to date completed work is not a good use of anybody’s afternoon. The rest have an even better defence. If a team genuinely does not know when something will ship, saying so is more honest than inventing a quarter, and I have spent enough words criticising game publishers for announcing dates with no basis in reality to be consistent about it here. I would rather have an empty field than a fictional one.

So let me narrow the complaint to what survives that. Atlassian has a Planned status for work that is genuinely uncommitted, and nine entries use it. Coming Soon is a different claim, and one hundred and eighteen entries make it with no timeframe behind them at all. If soon does not mean anything, the more honest label is already sitting in the dropdown beside it.

I should not throw that stone too hard from where I am standing. My own cloud migration series has been coming soon for a while now, and if I am honest with myself the accurate status on it is Planned.

And some of these blanks are not uncertainty at all. Search your own App updates page for “dot menu” and you will find a release note titled “Jira’s dot menu will be removed from August 19.” Change type, Removed. Rollout schedule, No timeframe yet. Status, Rollout Complete, for a removal that has not happened and will not for another two weeks. Filter that page to Coming Soon to see what is headed your way and you will not find it. It is filed under done.

Change Fatigue

None of this is abstract if you are the person absorbing it. Gartner has a name for it, change fatigue, and two of their own research directors put numbers to it in Harvard Business Review. The average employee absorbed two planned enterprise changes a year in 2016; by 2022 it was ten, and willingness to support them had fallen from 74 percent to 43. They sell change management advisory, so weigh it accordingly, but the direction is not really in dispute.

What it costs us specifically is the thing Gregory said at the top of this post. When the product moves this fast, knowledge stops compounding. A certification is a snapshot. So is a runbook, a training deck, a recorded walkthrough, and the answer you gave a user last quarter. Every one of them is worth slightly less the moment something ships, and at three changes a working day they depreciate faster than we can produce them. That is why his answer was a sandbox rather than a study guide, and why I still do not have a clean counterargument to it. The value has quietly moved from knowing the tool to being able to re-learn it on demand, which is a worse deal for everyone whose job involves explaining it to somebody else.

It shows up in smaller ways too. The person who stopped reading your change announcements did not get careless, they ran out. Tickets arrive for things working exactly as designed. And underneath all of it people stop assuming the tool will be the same tomorrow as it was today, which is the assumption everything else rests on.

The volume produces collisions, too, and the best example is a single word. In February, Atlassian renamed Jira projects to spaces, and the stated reason was to reduce confusion. Every admin I know had the same reaction inside of five minutes. Confluence has had spaces for as long as any of us can remember, and giving the container in both products the same name does not reduce confusion, it manufactures it. Then in July, Atlassian Projects arrived inside Jira, itself a rename of Atlas. The sequence is not a coincidence, and Atlassian has more or less said so. Jira projects had to become spaces so that Projects could mean the new thing.

Whatever you make of the destination, the part that keeps getting waved past is that words do not switch off. Jira has had projects for more than twenty years. There are two decades of documentation, training decks, runbooks, closed tickets, certification questions, and plain muscle memory built on that word, and none of it updates because a release note said so. That is not a change you are asking admins to absorb. It is a change you are asking every person we support to absorb, on the day, without warning, and we are the ones standing in the room explaining it.

Their own release notes have not managed the switch either. In a single seventeen day window this summer I can find “Board experience: Harmonized view for team-managed projects” sitting alongside “Customize your space during creation in Jira.” Neither is wrong. They cannot both stay right for long.

What I would ask for

It is smaller than slowing down.

Give the platform a version number. Pick a cadence, monthly or quarterly, name each one, and hold changes until the number ticks over. Not a marketing name for a seasonal launch, which Atlassian already does perfectly well, but a real version boundary an admin can point at when explaining to four hundred users why something moved. “We went to the September release last night” is a sentence an organization can plan around. “Something changed at some point” is not.

The frustrating part is that Atlassian already built most of this. Release tracks, on Premium and Enterprise, bundle changes and deliver them on the second Tuesday of each month with roughly two extra weeks of delay, and a sandbox on the preview track sees them a fortnight ahead of production. That is named, scheduled, previewable change management, and it works. It is also gated behind a plan tier, applied to a subset of changes, and never connected to the seasonal releases or the public changelog.

I would rather they formalized it than expanded it. Make the bundle the default way Jira changes, tell everybody the number, and let the paid tiers buy the sandbox and the delay rather than buying predictability itself.

Two smaller things, and unlike everything above, I think these ones could actually happen. Neither needs a roadmap, a plan tier, or anybody’s budget.

Use Planned when you mean planned. Coming Soon is a promise about time, and one hundred and eighteen entries are making it with nothing behind them. And let Rollout Complete mean the change has actually happened, because a removal scheduled for two weeks from now is not complete by any definition an admin would recognise.

Neither of those is a feature request. The statuses already exist. The taxonomy is already built. Somebody just has to decide the words should mean what they say, which is an afternoon and a style guide entry, not a quarter of engineering.

What actually shipped

Which brings me to the July batch itself, because it deserves better than being a statistic in someone else’s argument. Most of it is good.

Formula fields are the one worth sitting with longest. They are a calculation primitive on a work item, a value derived from other fields on the same item that recalculates as those change, and they arrive with four output types: numbers for budget variance or a RICE score, text for conditional labels like “at risk” that rewrite themselves as the inputs move, dates calculated from creation date or priority, and durations between two dates. The results are first-class Jira data rather than decoration, searchable and sortable in JQL, available on dashboards, able to trigger automation, and indexed by Rovo. Admins define a field once in the Custom Field Manager and scope it per space or globally, across both team-managed and company-managed projects, which is worth noting given how much of the rest of this release is team-managed only. That is a different kind of feature than adding a report. It is infrastructure, and infrastructure gets used in ways the launch note never anticipated.

One expectation to set, because Atlassian did not claim this and I suspect plenty of us will assume it anyway. This is not roll-up. SUM takes named fields on the same work item, written as SUM({field1}, {field2}), and there is no function anywhere in the documentation for children, subtasks, or parents. So how many story points are sitting under this epic is still not a question a formula field answers. If that is what you came for, the Marketplace has been solving it for years and is not about to stop. ScriptRunner’s scripted fields get there by being Groovy over REST calls rather than a fixed function library, so they can walk a hierarchy and amalgamate whatever they find, though Adaptavist’s own documentation notes the values only refresh when a work item is viewed or updated, which makes them unreliable in JQL filters. Decadis’ Advanced Formula Fields comes at the same problem from the formula side and goes considerably past what native supports. Atlassian’s version, to its credit, is the one that is properly indexed and fully searchable and sortable in JQL. It just cannot see past the work item it lives on.

Connecting a Loom meeting to a Jira space so Rovo turns the discussion into suggested work item updates is the one I have the most complicated feelings about. Once a recording is processed, Rovo maps decisions and action items out of the transcript onto specific work items and surfaces them for review. On its own merits that is a good idea. Nobody wants to translate a standup into ticket updates by hand.

My hesitation is not really about the feature, it is about the pattern around it. Loom has been turning up in places it did not organically grow for a while now. I cannot get through a specific ‘Plans for Jira’ Training Lab without something interrupting to ask whether I am aware Loom is a thing. I understand the commercial logic, and an acquisition that size has to show a return, but there is a difference between a product finding its use cases and a product being placed in front of you until you find one for it. This feature might genuinely be the former. It is hard to tell from inside the pattern.

The permission model underneath deserves its own look either way, before anyone gets excited about the demo. Who can connect a Loom space to a Jira space. Whose permissions the suggested updates inherit once applied. What the Teamwork Graph retains from a recording after somebody clicks apply. That sits close enough to the governance questions I am building an October talk around that it is getting its own post.

The software board got rebuilt on new infrastructure, and the scoping matters. This is team-managed spaces only. Company-managed is on the roadmap but not in this release, so if that is what you run, nothing on your boards moved. Team-managed gets a 22 percent faster load, the old 5,000 work item cap gone in favour of pagination at every level, refreshed swimlanes with collapsible columns, subtasks on cards, inline editing of priority and assignee, and a saved team default view. Two things for admins in there that are easy to miss: column configuration has moved out of space settings and onto the board itself, under the board menu, and done-item clearing now defaults to never on new boards. Atlassian’s line is that your workflows are not changing but the board underneath them is significantly better, which is true and is also the exact sentence that turns a rebuild into a change management problem before it is a feature. Somebody still has to explain to a room full of users why the board they have used for three years does not look the way it did last Tuesday, and “it is better now” does not land with the person who just wants their saved filter back where it was.

List and All Work merged into one view, now simply called List, bringing JQL, natural language search, full parent and child hierarchy, and inline editing together, with space admins able to save views the whole team shares. I will still miss the All Work tab, which did one job without asking me anything first. This one has already landed on my own instance, and it cost me a couple of minutes. Parent work items are collapsed by default, so I opened the new List, could not find a single one of my stories, and briefly assumed I had broken a filter. Nothing was broken. They were tucked under their parents. If you support anybody who lives in that view, that is the first ticket you are getting.

The natural language side is the part I want to dig into properly. Something is compiling a plain English question into a real query, and knowing what that compiler does with edge cases, and where it quietly guesses wrong, is exactly what JQL Deep Lore exists for.

The create experience now opens as a compact form with summary, description, assignee, due date and any required fields, expanding to the full form when a work item needs it. That should shave real time off the most repeated action in Jira. It also came with a wrinkle worth knowing about. The Summary field was briefly renamed Title, that got rolled back after feedback, and if you would rather not have the simplified form as your default at all, an admin can switch it off site wide under Settings, System, General Configurations, by setting Simple Create as Default to off.

The timeline now shows subtasks alongside everything else and lets you edit, filter, bulk-update and reschedule without leaving the view, with color bars by status category and a sprint view with release markers. Individual capacity planning arrived too, aimed at the perpetual question of who is actually free this sprint, which usually gets answered in a spreadsheet nobody trusts. Same caveat as the boards, though. Capacity is team-managed only for now, and the community thread asking when company-managed gets it does not have an answer yet.

Assets custom fields got redesigned, and this is the one most likely to matter on a Monday morning. The old cap was 20 objects per field. It is now 200 on work item and Portal screens, with pagination, bulk select and a Quick Add option, and existing fields scale automatically with nothing to reconfigure. Two things to file away. Supporting views like queues, boards and dashboards top out at 50 rather than 200, so that is the ceiling you meet first. And Atlassian has said 200 is hard and will not be raised, which is fine for most instances and a real constraint for anyone running asset-heavy Jira Service Management.

Two more rounded out the batch, both quality of life rather than new capability. Attachments got consolidated, so Confluence pages, Loom videos and file uploads live together in one section with filters and a grid view instead of scattered across a work item. And any work item can now generate an AI summary of what it is about, where it stands and what needs attention, which is useful for picking up somebody else’s ticket cold and worth a thought about what that summary is reading in order to produce it.

Wrapping Up

Atlassian has shipped a great deal this year so far, and most of it is good. The seasonal release program is the right idea, and I want it to work. What is still missing is smaller than a slowdown and larger than a label. Four in ten changes arrive with no date on them, every single Coming Soon is undated, and Rollout Complete does not mean the change has actually happened. None of those are engineering problems.

So go and open App updates on your own organization. Apps → Release management. Read the total, filter it to Coming Soon, and count how many of those can tell you when. Then look for anything already sitting on your instance that you did not know had landed. Mine said 1,010 this morning. It will say something different by the time you read this, and that is not a flaw in the measurement, that is the entire point.

The admin who has that page bookmarked is not the one who knows every feature. They are the one who stops being surprised, which is a different and considerably more useful thing to be. They are also the one feeling rather more overwhelmed this morning than they were yesterday. I am not going to pretend the number is comforting. It is just easier to plan around than a vague sense that things keep moving.

I’d like to know what number you get, because mine came from a Free tier org and I suspect the Enterprise ones are worse. And if you have a read on why that schedule field is empty on four in ten of these, I want to hear it, because I am guessing.

Until then, this is Rodney, asking: have you updated your Jira issues work items today?