Scaling Scrum in the Age of AI

In a previous article, The Future of Scrum in AI-Assisted Product Development, I argued that AI may radically change how software is created without necessarily changing Scrum itself.

The core empirical loop remains intact:

Plan → Build → Inspect → Adapt

AI changes the tools and tactics used inside that loop. Coding agents may write much of the software, generate tests, analyze defects, and assist with refinement, but Scrum still provides the mechanism for setting goals, producing increments, inspecting outcomes, and adapting.

The more challenging question arises when several Scrum Teams are working on the same product:

How should Scrum scale in an AI-assisted world?

Historically, scaling has often meant adding coordination structures, planning events, management roles, program backlogs, dependency boards, and synchronization mechanisms. But AI changes an important assumption underlying those approaches.

If smaller, AI-augmented teams can deliver more work independently, perhaps the scaling problem itself becomes smaller.

Scaling Is Really a Coordination Problem

It is tempting to think of scaling primarily in terms of the number of teams. Three teams require one level of coordination. Ten teams require another. Twenty teams require still more. But team count is only a proxy. The real issue is coupling.

Consider two organizations, each with ten delivery teams. The first organization is structured around multiple component teams, and almost every feature requires work from each of these teams:

• frontend
• backend
• database
• security
• integration
• testing
• infrastructure

A single customer feature may cross five or six organizational boundaries before it can be delivered. That organization has a significant scaling problem. Now consider another organization with ten genuinely cross-functional teams. Each team can take a product backlog item and deliver it end-to-end with minimal reliance on other teams.

The two organizations have the same number of teams. But they do not have the same coordination challenge. This suggests an important principle: Coordination cost scales with dependency density, not simply with team count. That distinction becomes increasingly important as AI improves the delivery capability of individual teams.

AI May Make Teams More Genuinely Cross-Functional

One of the traditional reasons for building large cross-functional teams was the need to bring together many different technical specialties. A single product feature might require frontend development, backend services, database changes, automated testing, infrastructure work, security review, and documentation. If those capabilities were distributed across separate specialist teams, every feature created handoffs and dependencies.

Modern coding agents are increasingly capable of taking an end-to-end product feature from requirement through implementation and testing. They may internally use multiple tools, models, or specialized subagents, but that complexity does not necessarily need to become organizational complexity. From the product team’s perspective, the important question is much simpler: can the team take a Product Backlog item and deliver it as a Done Increment without relying heavily on other teams?

In an AI-assisted model, a smaller group of people may achieve the same breadth by supervising agents capable of working across the full technology stack. A single team member might guide an agent through user-interface changes, service logic, data persistence, testing, and integration for a complete product feature.

Consider an e-commerce product with capabilities such as registration and login, search, product details, shopping cart, payments, shipments, and returns. If the Product Backlog contains value-stream-aligned features within these areas, a team member could take responsibility for a complete feature and use AI agents to build and test it end to end. The work is organized around customer capability rather than technical layers.

A backlog containing items such as “create database table,” “build API endpoint,” and “modify user interface” naturally reinforces specialization and handoffs. A backlog containing items such as “allow customers to check out as a guest” or “allow customers to change a shipping address before dispatch” encourages end-to-end ownership.

The pairing of value-stream-aligned backlog items and end-to-end capable AI agents can therefore make team autonomy much more achievable. The important design question is no longer whether every technical specialty is represented by a separate person. It is whether the team, supported by AI, possesses everything necessary to turn a Product Backlog item into a usable product increment.

Product area	Human owner	Agent workload
Registration/Login	Product engineer A	Build/test identity features (end-to-end)
Search	Product engineer B	Build/test search features (end-to-end)
Product Details	Product engineer C	Build/test catalog experience (end-to-end)
Shopping Cart	Product engineer D	Build/test cart capabilities (end-to-end)
Payments	Product engineer E	Build/test payment functionality (end-to-end)

These are not five separate delivery teams. Together, the five engineers form a single cross-functional product team. The product areas represent temporary areas of focus rather than permanent organizational boundaries. As priorities change, engineers can shift between areas while AI agents provide much of the implementation capacity. What the table really suggests is  one small product team composed of five product engineers, each temporarily stewarding a different part of the product value stream while using AI agents to deliver features end to end.

So instead of:

5 product areas → 5 teams → perhaps 30–40 people

you might have:

5 product areas → 1 product team → 5 product engineers + AI agents

The human team then owns the whole product.

That has several advantages.

• First, coordination happens inside one team rather than across teams. Registration, Search, Cart, and Payments are no longer organizational silos. They are areas of focus within one product team.
• Second, the engineers can move between areas as demand changes. If Payments becomes the priority, two or three engineers can focus there temporarily. You avoid turning the product areas into permanent ownership boundaries.
• Third, the Product Backlog becomes even more meaningful. There is no need to decide which “team” owns a feature. The product team simply pulls the highest-value work.
• Fourth, the scaling problem may disappear entirely until the product becomes too large for one human team to manage effectively.

That may be the strongest implication yet: AI may reduce not only team size, but the number of teams required to deliver a product. And once you reduce the number of teams, a large portion of the traditional scaling problem vanishes with it.

This also has important implications for scaling. Greater end-to-end capability reduces handoffs, dependencies, and the number of people required to deliver a product. As dependency density falls, the need for elaborate coordination structures falls with it.

The objective should therefore not be to create more sophisticated mechanisms for coordinating specialist teams. It should be to design products, backlogs, architectures, and AI-assisted teams so that as much work as possible can be delivered independently.

Start With One Product

A simple scaled Scrum model could begin with:

One Product Goal–>One Product Backlog–>Multiple cross-functional Scrum Teams–>One integrated product

Here is an important starting point: Scaling should not automatically create separate planning structures between Product Management and the teams. If all teams are contributing to the same product, a single Product Backlog can remain the primary source of delivery demand. The backlog represents the ordered supply of work available to the delivery system. Teams pull from it as capacity becomes available.

That is very different from dividing the product backlog months in advance into separate team queues (“PI Planning”).

Discovery Should Feed the Product Backlog Continuously

Before work reaches the Product Backlog in a delivery-ready state, it must usually pass through some form of product discovery. A lightweight upstream Discovery Kanban might look like:

Funnel → Assess → Refine → Ready

Its job is to transform product ideas, hypotheses, customer problems, and strategic priorities into backlog items sufficiently understood to justify delivery investment. The output is not a detailed project plan.

The output is: An ordered supply of validated, sufficiently refined work ready for teams to pull.

This creates a clean separation:

Discovery determines what is worth building. The Product Backlog represents validated intent, economic prioritization, and technical readiness for implementation. 

An upstream discovery and intake Kanban exists to ensure only economically-justified and delivery-ready work enters the delivery system. That is its operational purpose. Without it, the Product Backlog becomes a blended space containing both ready delivery work and unresolved demand. Once that happens, the backlog loses its usefulness as a pull queue. And once the backlog loses its usefulness as a pull queue, the organization begins to depend more heavily on episodic planning and negotiation to keep moving. That is the pattern we need to break to minimize scaling overhead.

AI can assist significantly in Discovery through research synthesis, hypothesis generation, prototype creation, backlog analysis, dependency detection, and acceptance-criteria generation. Human Product Management remains accountable for product decisions.

Teams Pull Rather Than Receive Assigned Work

Suppose eight Scrum Teams are working on the same product. The Product Backlog contains value-stream-aligned items that can be delivered largely independently. At the beginning of a Sprint, each team pulls the most valuable appropriate Ready work into its Sprint Backlog.

That gives us:

One Product Backlog from which each team creates their Sprint Backlog for the next sprint: –>

Team A → Sprint Backlog

Team B → Sprint Backlog

Team C → Sprint Backlog

and so on.

There is no requirement to create eight persistent team backlogs several months in advance (PI Planning). Preallocating work to teams creates planning inventory. And constrains flexibility. If Team C suddenly has capacity but the next valuable item has been assigned to Team F, the organization must renegotiate the plan rather than simply pulling the next most valuable piece of work.

A pull system works differently.

Teams pull work when they have capacity rather than receiving work according to a distant forecast.

That is a much more adaptive model.

The Product Flow Sync

AI does not mean coordination disappears. It means coordination can become lighter, more focused, and more empirical.  In a pull-based, multi-team Scrum model, some mechanism is still needed to maintain coherence across the overall product delivery system. Individual Scrum Teams manage their own Sprint execution through Scrum’s normal inspect-and-adapt cycle, but certain problems emerge only at the product level. These include excessive work-in-progress, aging backlog items, cross-team dependencies, integration constraints, shared-resource bottlenecks, and instability in overall delivery flow.

A Product Flow Sync provides the control mechanism for addressing these conditions. Its purpose is not to coordinate teams against a predetermined multi-Sprint delivery plan, nor is it a forum for collecting status reports. Instead, it inspects the behavior of the product delivery system and asks a different question: Is work flowing predictably from the Product Backlog through the Scrum Teams and into the integrated product?

The discussion therefore focuses on operational signals across the product rather than on whether individual teams are “on plan.” Product-level work-in-progress, item aging, blocked work, throughput stability, integration problems, and emerging dependencies provide evidence about the health of the delivery system. If several teams are accumulating aging work, if dependencies are beginning to constrain flow, or if throughput becomes unstable, these are signals that the system may require intervention.

The Product Flow Sync does not centrally manage the Scrum Teams or assign work to them. Teams remain responsible for establishing their Sprint Goals, creating their Sprint Backlogs, and adapting their plans during the Sprint. The product-level control mechanism intervenes only where conditions affect the broader delivery system.

Corrective actions might include reordering the Product Backlog, reducing product-level work-in-progress, swarming a blocked item, resolving a dependency between teams, addressing an architectural or integration constraint, or temporarily slowing the intake of new work. In some cases, the appropriate action may simply be to make a constraint visible and allow the affected teams to resolve it directly.

The Product Flow Sync therefore complements Scrum rather than replacing any Scrum event. Scrum provides the empirical control loop within each team (and provides the cadence to ensure effective inspection/adaptation):

Plan → Build → Inspect → Adapt

The Product Flow Sync creates an additional empirical loop above the individual Scrum Teams, and extends that same empirical principle across the multi-team product system:

Sense → Evaluate → Adjust

What is being ‘sensed’ here are product-level flow signals: throughput, cycle-time, WIP, and aging. The objective is not centralized control of execution. It is to maintain the conditions under which autonomous Scrum Teams can continue to pull work and deliver value independently while the product as a whole remains coherent and flows predictably.

The two loops complement one another.

AI Can Reduce the Cost of Coordination

In a traditional multi-team delivery system, a significant amount of coordination effort is spent simply gathering information. Teams report what is in progress, which items are blocked, where dependencies exist, and whether work is slipping. Much of that activity exists because the broader product system does not have a reliable, continuously updated view of its own flow.

In an AI-assisted operating model, much of this sensing work can be automated. Delivery-management systems such as Jira already contain most of the raw data needed to derive a small set of useful flow signals, including work-in-progress, item aging, throughput, and blocked work. Rather than relying on teams to manually report status, these signals can be calculated continuously and presented through a simple product-level flow dashboard.

The objective is not to create another large management reporting system. A small number of well-chosen indicators is usually enough to determine whether the delivery system is operating normally or whether intervention may be required. Rising WIP, increasing numbers of aging items, unstable throughput, or persistent blocked work are all signals that flow may be under stress.

AI can add an interpretation layer on top of those metrics. It can summarize recent changes, identify unusual patterns, highlight concentrations of aging or blocked work, and suggest where the Product Flow Sync should focus its attention. For example, the system might identify that product-level WIP has increased for three consecutive weeks while throughput has declined, or that several of the oldest backlog items depend on the same shared service.

The AI does not make the control decision. The Product Flow Sync remains the controller. Its role is to inspect the signals and determine whether corrective action is needed. That action might include pausing the intake of new work, swarming an aging item, resolving a cross-team dependency, changing a WIP limit, reordering the Product Backlog, or escalating a systemic constraint.

This changes the nature of coordination. Teams no longer need to spend large amounts of time explaining what they are doing so that someone else can reconstruct the state of the system. The delivery system itself provides the signals. People can then focus their attention on the more important question: Does anything need to change?

AI therefore reduces the cost of coordination not by eliminating coordination, but by automating much of the information collection and interpretation that coordination previously required. The result is a more lightweight, exception-driven control model in which teams remain autonomous and product-level intervention occurs only when the flow signals indicate that it is necessary.

Humans still make the decisions. But AI can make the coordination system increasingly exception-driven rather than meeting-driven. That may be one of the biggest changes AI brings to scaled delivery.

Plan Only What Needs to Be Planned

At scale, some product-level planning is still required.

A Product Goal or vision must be translated into:

• product hypotheses
• validated backlog items
• priorities
• architectural constraints
• dependencies
• sequencing considerations

But that does not mean the organization has to construct a detailed multi-team delivery plan covering the next ten or twelve weeks.

There is a major difference between: Planning the product and Scheduling all future work.

A scaled Scrum model should do the first without unnecessarily doing the second. Product-level planning should ensure there is a coherent Product Backlog and sufficient Ready work. Sprint Planning should remain the point where teams make detailed execution decisions.

When Is a Larger Planning Event Needed?

There may still be situations where longer-horizon coordination becomes necessary.

For example:

• several features require coordinated work across many teams
• major architectural changes must happen in sequence
• external milestones create synchronization constraints
• shared infrastructure becomes a bottleneck
• regulatory or contractual commitments require coordinated delivery
• teams repeatedly discover dependencies too late

In those circumstances, a larger product-planning event may add value. But it should only be introduced when the delivery system demonstrates a need for it, not simply because a particular number of teams has been reached. A useful rule is:

Introduce additional planning when the cost of unresolved coordination exceeds the cost of the planning mechanism.

That is a very different principle from assuming that ten teams automatically require a particular scaling framework.

How Many Teams Can One Product Backlog Support?

Traditional scaling guidance often places practical limits around a handful of teams. But AI may change those limits considerably. However, there is no universal number.

If an organization has:

• value-stream-aligned backlog items
• genuinely cross-functional teams
• low dependency density
• continuous integration
• strong automated testing
• clear product boundaries
• AI-assisted coordination
• effective product-level control

then there is no obvious reason why eight, ten, or perhaps more teams could not work successfully from one Product Backlog. The limiting factor becomes less the number of teams and more the amount of coupling between them.

This leads to a better scaling question:

Can each team independently take a Ready backlog item and deliver it into the integrated product?

If the answer is usually yes, scaling remains relatively simple. If the answer is usually no, additional coordination will be required.

The Product Becomes the Scaling Unit

Traditional enterprise delivery models frequently introduce a program layer between strategy and teams. But if multiple autonomous teams are contributing directly to one coherent product, that intermediate layer may not always be necessary.

The structure can become:

Strategy –> Product –> Scrum Teams

The product—not the program—becomes the natural unit of scaling. The Product Goal establishes direction.

• Discovery supplies validated work.
• The Product Backlog orders that work.
• Scrum Teams pull and deliver.
• Product telemetry and customer feedback provide evidence.
• A product-level control loop adapts direction and priorities.

That is a much simpler operating model.

Scrum Remains Scrum

Perhaps the most interesting outcome is that Scrum itself does not have to change very much.

Teams still:

• establish Sprint Goals
• select work
• create increments
• inspect results
• adapt

AI may radically change the way they accomplish those activities. But the empirical framework remains intact. The larger change occurs in the structures surrounding the teams.

Organizations may need less:

• centralized work allocation
• long-range team scheduling
• dependency administration
• status reporting
• large coordination ceremonies

and more:

• continuous discovery
• value-stream-aligned backlog items
• autonomous delivery teams
• product-level flow
• rapid feedback
• lightweight control
• AI-assisted sensing and analysis

Scale by Removing Coupling

The traditional response to scale has often been: More teams require more coordination.

The AI-assisted response may increasingly become: More capable teams should require less coordination.

That leads to a different scaling philosophy. Do not begin by adding layers. Begin by asking:

• Can we make the teams more cross-functional?
• Can we align backlog items to end-to-end value?
• Can we reduce shared dependencies?
• Can architecture support independent delivery?
• Can teams pull rather than receive assigned work?
• Can AI surface coordination issues automatically?
• Can we manage the remaining exceptions with a lightweight product-level control loop?

Only after those questions have been addressed should additional scaling machinery be considered. The objective is not to eliminate coordination completely. It is to avoid institutionalizing coordination that good product design, team design, architecture, and AI assistance can make unnecessary.

Perhaps the emerging principle for scaled Scrum in the age of AI is therefore:

One product. One Product Backlog. Autonomous AI-augmented Scrum Teams. Just enough coordination.

Scale by preserving autonomy. Design out dependencies wherever possible. And add control only where the remaining coupling genuinely requires it.

Final Thoughts

The central question in scaling Scrum is not how many teams are involved. It is how much coordination those teams actually require. In a traditional environment, scaling frameworks often emerge because work is fragmented across specialist teams, dependencies are common, and significant effort is needed to align execution.

AI may change those conditions. If smaller teams can use AI agents to deliver end-to-end product features, and if the Product Backlog is organized around value-stream-aligned work, then much of the coordination overhead that organizations have historically accepted as inevitable may no longer be necessary. The scaling problem becomes smaller because the dependency problem becomes smaller.

This does not mean coordination disappears. It means coordination can become lighter, more focused, and more empirical. A single Product Backlog, continuous discovery, pull-based team execution, and a product-level flow control loop may be enough for many multi-team environments. Scrum itself remains largely intact. Teams still plan, build, inspect, and adapt. What changes is the surrounding operating model.

That is why the future of scaled Scrum may not be about adding more layers of structure. It may be about removing unnecessary ones. As AI increases the delivery capability of teams, the challenge is no longer to create ever more sophisticated coordination mechanisms. It is to design products, teams, backlogs, and control systems so that coordination is needed only where real coupling remains.

The emerging principle is a simple one: one product, one Product Backlog, autonomous AI-augmented Scrum Teams, and just enough coordination to maintain flow.