It has worked for over twenty years. It has given teams a shared language, a rhythm and a structure that keeps people on track. Millions of product teams around the world run standups, sprint planning, refinement and retros. That is not a coincidence. It solves a real problem.
The problem is just that the problem is disappearing.
What Scrum actually does
Take Scrum’s ceremonies apart and look at what they actually do.
Daily standup: information routing. What did you do yesterday. What are you doing today. Are you blocked. It’s a synchronization protocol disguised as a meeting. The purpose is that everyone in the room knows what everyone else is doing.
Sprint planning: translation. Take business needs, translate them into tasks, distribute them among people. It’s coordination disguised as planning.
Refinement: collective guessing game. The whole team sits estimating things nobody knows enough about yet. It’s uncertainty management, expensive uncertainty management, because we don’t have a better system for understanding how big things are before we build them.
Retro: the only ceremony about something other than coordination. It’s about learning, reflection, improvement. And it’s probably no coincidence that it’s the ceremony most teams skip or run half-heartedly.
The point is not that Scrum is bad. The point is that Scrum is a coordination framework. It solves the problem of “how do we keep track of who’s doing what, and how do we make sure information flows between people who otherwise wouldn’t talk.”
That is an important function. But it’s also a vulnerable one.
AI is exceptionally good at coordination
One of the things AI seems to be best at, by far, is gathering information across sources, keeping track of who’s doing what, and connecting things across all the data a company already has lying around.
A system that knows what everyone is working on can replace standups. A system that understands capacity and dependencies can replace sprint planning. A system that can analyze velocity and blockers in real time can make half of a retro redundant.
That’s not science fiction. That’s MCP servers, browser agents and context windows growing month by month. The building blocks are already there. The orchestration is missing. But it’s coming.
And when it comes, Scrum has a problem. Because the framework you’re running is designed to solve a problem that a system will soon solve better than you.
The roles fall apart too
Scrum assumes fixed roles with fixed responsibilities. A Product Owner who prioritizes the backlog. A Scrum Master who facilitates the process. Developers who build.
But the classic product trio, PM, designer, developer, is falling apart. Code is becoming a commodity. UI design likewise. A PM can ship. A developer can design. The lines between the roles are fluid, and they get more fluid every month.
I think the new triangle looks different. The generalist who understands users and business and can ship on their own. The architect who doesn’t write the code but validates that it all holds together. The compliance anchor who holds the line on security, GDPR and regulation, because risk grows as code gets written faster.
Those are not three new job titles. They are three new responsibilities. And they don’t fit into Scrum’s role boxes.
Outcome, not output
Here is what truly challenges Scrum: the framework measures the wrong things.
Velocity. Story points. Burndown charts. Those are output metrics. They tell you how much you built, not what it led to.
But we always start with an outcome in mind. More conversions. Faster onboarding. Fewer support tickets. And then we spend half our time guessing which output gets us there. Then we write that output down in tickets. Estimate them. Distribute them. And measure whether we hit all of them by the deadline.
Imagine skipping that step.
Imagine telling your system: “I want new users through onboarding 30 seconds faster.” And the system gets to work. Looks at the flow. Tests three variants. Puts the winner in production. No ticket. No sprint. No refinement.
Nobody asked “how many story points is that?”
This is not an argument for chaos. It’s an argument that the structure we have measures the wrong thing.
So what’s left?
If the coordination disappears and the roles turn fluid, what’s left?
What was always the most important thing, but what we rarely had time for.
Understanding customers deeply. Making the decisions nobody else dares to make. Holding a direction when the data is unclear. Sensing what’s going on in a room full of people. Saying no to the feature everyone wants, because you know it’s wrong.
Those are not ceremonies. That is judgment. And judgment cannot be put in a sprint.
Scrum won’t disappear tomorrow. But its foundation, that coordination requires human effort, is disappearing. And when the foundation goes, everything built on top of it goes too.
The question is not “how do we use AI in Scrum?”
It’s “what do we do that isn’t coordination?”
And that question should worry anyone who has built a career on facilitating, synchronizing and keeping people aligned. Not because the work was pointless. But because it’s being automated.
What’s left is what should always have filled most of the day. Now it gets the chance.