Scrum helped teams escape large up-front plans, long feedback cycles, and the fiction that software work can be predicted months in advance. For many organizations, it is still a useful introduction to Agile thinking because it creates rhythm, focus, and regular inspection.
But AI is putting new pressure on Scrum. Not because Scrum is bad, and not because AI has made software development magically easy. The problem is that AI changes the pace of delivery unevenly.
But AI is putting new pressure on Scrum. Not because Scrum is bad, and not because AI has made software development magically easy. The problem is that AI changes the pace of delivery unevenly.
AI Speeds Up Code, Not the Whole System
Some development tasks now collapse from days to hours. With the right context, prompt, and tool, developers can move incredibly fast. Refactoring, boilerplate, test scaffolding, documentation, and familiar implementation patterns can often be completed much faster than before.
But the rest of the delivery system does not automatically speed up with it. Understanding the business need still takes time. Clarifying requirements still takes time. Stakeholders still need to answer questions. Users still need to review and test changes. Other teams still need to coordinate dependencies.
AI may accelerate coding, but it does not magically make everyone else available when feedback is needed. Development may move faster, while requirements definition, validation, coordination, and stakeholder feedback still move at human speed.
But the rest of the delivery system does not automatically speed up with it. Understanding the business need still takes time. Clarifying requirements still takes time. Stakeholders still need to answer questions. Users still need to review and test changes. Other teams still need to coordinate dependencies.
AI may accelerate coding, but it does not magically make everyone else available when feedback is needed. Development may move faster, while requirements definition, validation, coordination, and stakeholder feedback still move at human speed.
AI Also Makes Work Less Predictable
AI does not just make work faster. It makes effort more variable.
A story that appears complicated may be completed in a morning with the right AI assistance. Another story that appears straightforward may turn into days of prompt refinement, failed approaches, and validation.
Worse, AI does not always fail obviously. Sometimes it produces plausible solutions that are just wrong enough to waste time. It may misunderstand the domain, invent an API behavior, miss a business rule, or keep generating variations of an approach that will never work.
That variability is hard on systems built around short-term commitments.
A story that appears complicated may be completed in a morning with the right AI assistance. Another story that appears straightforward may turn into days of prompt refinement, failed approaches, and validation.
Worse, AI does not always fail obviously. Sometimes it produces plausible solutions that are just wrong enough to waste time. It may misunderstand the domain, invent an API behavior, miss a business rule, or keep generating variations of an approach that will never work.
That variability is hard on systems built around short-term commitments.
Why This Pressures Scrum
Scrum does not require perfect estimates. Agile teams have always known estimates are imperfect. But Sprint Planning still depends on some level of short-term predictability. The team looks at the backlog, considers capacity, discusses the work, and decides what it believes it can accomplish during the Sprint.
AI weakens that confidence.
It is no longer enough to ask, “Can the development team complete this work inside the Sprint?” The better question is, “Can the entire delivery system support this work inside the Sprint?”
That is harder to know. Requirements may need to be clarified faster. Stakeholder conversations may need to happen more frequently. Testing and feedback may be needed almost continuously, even though reviewing software is not the stakeholder’s full-time job.
Scrum still provides value. But as effort becomes more volatile and feedback needs become less predictable, Sprint commitments become more fragile. Velocity gets noisier. Planning starts to depend on assumptions the team may not be able to validate until work is underway.
AI weakens that confidence.
It is no longer enough to ask, “Can the development team complete this work inside the Sprint?” The better question is, “Can the entire delivery system support this work inside the Sprint?”
That is harder to know. Requirements may need to be clarified faster. Stakeholder conversations may need to happen more frequently. Testing and feedback may be needed almost continuously, even though reviewing software is not the stakeholder’s full-time job.
Scrum still provides value. But as effort becomes more volatile and feedback needs become less predictable, Sprint commitments become more fragile. Velocity gets noisier. Planning starts to depend on assumptions the team may not be able to validate until work is underway.
Shorter Sprints Only Solve Part of the Problem
When AI increases throughput, one response is to shorten the Sprint. That can help when the problem is cadence. If the team is producing meaningful increments faster than the Sprint cycle allows for review, reprioritization, or release, a shorter Sprint can reduce waiting and tighten the feedback loop.
But shorter Sprints do not solve uncertainty. A two-day Sprint does not make stakeholders more available. It does not make requirements clearer. It does not remove dependencies. It does not make validation effortless. It does not prevent AI from producing a plausible solution that later turns out to be wrong.
Shorter Sprints help when the team is waiting on the process. They do not help much when the work is waiting on the system.
If the constraint keeps moving from coding, to clarification, to review, to validation, to stakeholder feedback, then the team may not need a smaller time box. It may need a flow-based model.
But shorter Sprints do not solve uncertainty. A two-day Sprint does not make stakeholders more available. It does not make requirements clearer. It does not remove dependencies. It does not make validation effortless. It does not prevent AI from producing a plausible solution that later turns out to be wrong.
Shorter Sprints help when the team is waiting on the process. They do not help much when the work is waiting on the system.
If the constraint keeps moving from coding, to clarification, to review, to validation, to stakeholder feedback, then the team may not need a smaller time box. It may need a flow-based model.
Why Kanban Fits Better
Kanban fits the AI era better because it focuses on flow across the whole delivery system.
It does not make stakeholders instantly available. It does not make requirements automatically clear. It does not make validation effortless. The same bottlenecks still exist.
The difference is that Kanban makes those bottlenecks visible as they happen.
Instead of asking, “How much can we commit to completing in this Sprint?” Kanban asks what is most important next, how much work is already active, where work is blocked, what is waiting for feedback, and what constraint is slowing flow right now.
Those questions fit AI-assisted development because AI changes where the constraint appears. Some days the bottleneck is coding. Other days it is stakeholder input, testing, security review, requirements clarification, or untangling a bad AI-generated path.
Kanban does not remove uncertainty. It manages it more directly. Work is visible. Work in progress is limited. Blocked items stand out. Aging work gets attention. Priorities can adjust continuously instead of waiting for the next Sprint boundary.
That matters because AI makes starting work easier. But starting work is not delivering value. Kanban pushes back against that. It reminds teams that finishing matters.
It does not make stakeholders instantly available. It does not make requirements automatically clear. It does not make validation effortless. The same bottlenecks still exist.
The difference is that Kanban makes those bottlenecks visible as they happen.
Instead of asking, “How much can we commit to completing in this Sprint?” Kanban asks what is most important next, how much work is already active, where work is blocked, what is waiting for feedback, and what constraint is slowing flow right now.
Those questions fit AI-assisted development because AI changes where the constraint appears. Some days the bottleneck is coding. Other days it is stakeholder input, testing, security review, requirements clarification, or untangling a bad AI-generated path.
Kanban does not remove uncertainty. It manages it more directly. Work is visible. Work in progress is limited. Blocked items stand out. Aging work gets attention. Priorities can adjust continuously instead of waiting for the next Sprint boundary.
That matters because AI makes starting work easier. But starting work is not delivering value. Kanban pushes back against that. It reminds teams that finishing matters.
Flow Beats Prediction
Scrum can still work in this environment. But for teams already comfortable with Agile thinking, Kanban may be a better fit for what AI is doing to the work itself.
AI changes delivery unevenly. It speeds up some work, leaves other work mostly unchanged, and sometimes creates false progress that must be unwound. That makes prediction harder and flow more important.
When effort stops behaving predictably, the best system is the one that stops pretending it will.
AI changes delivery unevenly. It speeds up some work, leaves other work mostly unchanged, and sometimes creates false progress that must be unwound. That makes prediction harder and flow more important.
When effort stops behaving predictably, the best system is the one that stops pretending it will.
About the Author
Andrew Anderson is the President of Latitude 40 and a seasoned technology leader with over two decades of experience in software development and process improvement. He helps organizations achieve operational excellence through practical, low‑risk strategies that deliver measurable results. His work combines technical expertise with a commitment to agility, guiding teams toward smarter solutions and sustainable growth.
About Latitude 40
Latitude 40 works with companies that are tired of over-engineered solutions and unreliable plans. We build custom software and help teams move away from rigid project thinking toward more adaptive, reality-driven execution.
Our focus is simple: reduce risk, improve flow, and help organizations deliver meaningful results without unnecessary complexity.
If you want to see what a fast, responsible start could look like for your organization, we would be glad to walk through a practical first step.
Our focus is simple: reduce risk, improve flow, and help organizations deliver meaningful results without unnecessary complexity.
If you want to see what a fast, responsible start could look like for your organization, we would be glad to walk through a practical first step.
RSS Feed
