AI -The swansong of Scrum?

What’s left of Scrum in an AI-driven Software Delivery Life Cycle (SDLC)  

Now, an SDLC contains the same steps before and after AI. You need requirements, you need to code, you need to assure the quality of your code, and ultimately deploy and monitor it.  

How Does AI Change Requirements Management in Scrum? 

Requirements, or what the team intends to build, are included in the product backlog and sprint backlog artifacts and reside primarily in the product owner role domain. AI can help you analyze product performance, stakeholder input, and customer feedback, and generate product backlog items grounded in relevant guidelines and regulations. Here is one of my earlier articles exploring this a bit further.  

AI can analyze things, suggest options, and generate items, but we still need human oversight. Not only to safeguard quality through human judgment, but also to empathize and make decisions based on the WHY of your product instead of WHAT.  

Understanding how the backlog forms and evolves has always been a challenge in Scrum. However, it is essential that the backlog exists and is organized into a prioritized list. AI can do a lot, but not everything. So, does that make the product owner (PO) safe? Maybe a little. Because I think this is an important role. If you look at it from a pure PO perspective, rather than from a product management standpoint, I think a large part can be assisted by AI. This would allow developers to transition into this area and develop their skills in requirement engineering.  

What Happens to Scrum Teams in an AI-Driven SDLC? 

The concept of a development team is, in fact, a bit different in an AI world. Agents write code, ensure quality, communicate, etc., etc. A single full-stack engineer could lead multiple agent flows in parallel, orchestrating, checking, and improving them. With regular teams, I often tried to get people to work outside their primary disciplines, like a developer doing QA. There would always be resistance, and it’s likely this saying will be used; you can’t have a butcher who’ qualifies their own meat. This means you would be unable to test your own code objectively. This is, of course, no longer the case when the agent actually generates the code. For a single engineer, the scope of this responsibility is determined horizontally and, vertically as depicted below.  

With this, the concept of “team” needs to be reconsidered at least, if not discarded entirely.  

So, if a team is a debatable concept in the world of AI-assisted SDLC’s, where does that leave the Scrum Master role? We can be certain of two things: everything will go wrong, and there is always room for improvement. Assisted by AI, people could be tasked with addressing impediments and making improvements. Analyzing patterns, problems and pulling people and AI together to improve. Since there is quite a lot of control already in the form of the developer orchestrating its agents’ flows, the Scrum Master role could be moving away more to the (eco)system level and more to developer experience, becoming more of a system optimizer, focused on how effectively we are leveraging the technology and where we can grow.  

How Does AI Affect Self-Organization in Scrum? 

Self-organization has always been about trusting teams to decide how to do their work in the way they see best. This also includes the tools used in their craft.  

This is still the case, even when a significant part of that work is delegated to AI, and engineers don’t really work in teams anymore. Self-organization is about how individuals and small groups decide to design, steer, and trust their AI-supported workflows.  

The autonomy remains, but the nature of the decisions changes: deciding what to automate, what to keep manual, what the standards are, and how to balance control and speed.  

Where it becomes interesting is how much freedom developers have and what the limiting factors are. For example, cost control, quality control, regulatory pressure, auditability, etc. It might make sense to go from ‘everyone can use everything’ to a more centrally approved set of tools or even fixed sets for specific purposes.  

Do Scrum Ceremonies Still Matter in AI-Driven Development? 

Scrum events were designed to create rhythm and ensure feedback. But if generating, testing, and iterating on software becomes something you can do in hours instead of days, the need for fixed cadences starts to fade.  

Why wait for a sprint review if you can get meaningful feedback continuously? Why lock yourself into a plan for two weeks if the cost of changing direction has dropped so significantly?  

The feedback loops do not disappear. They become more continuous, more lightweight, and less tied to predefined ceremonies. Rather, they will run in production, validating assumptions and gathering real data on the outcome.  

A more interesting thought might be found in the theory of constraints. Since the actual development of a new increment is no longer a bottleneck (aside from mismanagement at Uber), the bottleneck will shift to the next stage: the level of change your clients can absorb into their products. Are you actually running wild for a ton of new features coming to your favorite apps every week? It depends on your product; a video game producer could very well benefit from a high rate of qualitative updates, but your banking app might be a very different story.  

Maybe these companies could use their development power in directions they were previously unable to pursue: diversifying services and portfolios, opening new markets, launching new brands, and spreading faster rather than optimizing their current products too far.  

My conclusion is that the intention behind Scrum events based on feedback loops remains valid. The form might not.  

There are other often associated practices connected to Scrum:.  

Some of the commonly used practices in Scrum are becoming increasingly artificial. Take something like “velocity” and estimation. There is so much to say about these concepts and even without AI, they get debated to death.  

But when AI can generate large parts of a solution close to instantly, what does it actually matter how complex something is, or how much effort it takes? I think this whole topic should be either reimagined or discarded. And both outcomes are fine. Maybe it forces us to face the facts and acknowledge that we were never in full control.  

Do Scrum’s Core Pillars and Values Still Matter in an AI-Native SDLC? 

Interestingly enough, the core pillars of Scrum remain surprisingly intact, or maybe even become more important in the AI native SDLC.  

Transparency is still essential, perhaps even more so when AI systems operate with a level of complexity that is hard to oversee. Inspection becomes richer because you have more data, faster. Adaptation becomes more frequent because change is largely easier to implement in the AI agent (flow).  

The values also hold. Focus becomes even more about directing attention to the right value in an environment that can produce potentially infinite output. Openness becomes critical when working with opaque systems. Courage is required to let go of old structures. Commitment shifts toward outcomes rather than processes. Respect extends to how humans respect their roles and add value towards the AI with which they collaborate. I believe this part of Scrum survives better than its structure.  

Conclusion  

The core of Scrum still stands. It is the decorum that changes. What used to be a clear structure around roles, events, and artifacts becomes more fluid in an AI-driven SDLC. Product Owners are pushed to grow into true product management. Scrum Masters shift toward system-level thinking and developer experience. Developers spend less time on coordination overhead and more time orchestrating effective agent flows and making better decisions.  

Development capacity is no longer the primary constraint. The real constraint becomes understanding the problem, making the right choices, steering the system effectively, and most importantly, adjusting the speed to your client’s acceptance level and expectations.  

So, is AI the swansong of Scrum?  

Not really. But it might be the swansong of how we have been using it.  

And maybe that is exactly what Scrum itself always asks us to do: inspect, adapt, and let go when something no longer serves its purpose.