No, agile isn’t dead, but agile in the age of AI looks different: the values (short feedback loops, working software, talking to customers) hold up, while several ceremonies built around expensive code do not. My verdict is to keep the retro and the customer review, rework planning and standups, and drop story-point estimation and most backlog grooming meetings.
Key Takeaways
- Agile isn’t dead, but ceremonies built around expensive code (story points, velocity, long planning) lose their point when AI writes much of it.
- Keep the retro and customer review, change planning and standups, and kill estimation points and most backlog grooming meetings.
- Review and decision-making become the bottleneck when AI speeds up coding, not development.
- Start from the customer problem before applying AI, as Scrum.org advises.
- Scrum masters and project managers don’t vanish, but pure facilitation and status reporting do.
In this article
- Is agile dead in the age of AI?
- What AI breaks in agile sprints in the age of AI
- Agile in the age of AI, ceremony by ceremony: keep, change or kill
- A sprint example: where AI sped things up and review jammed
- Where teams miss AI: retros and user research
- Will AI replace scrum masters and project managers?
- A lightweight setup for agile in the age of AI for a small Indian team
- What I’m changing in my advice, as of October 2026
Is agile dead in the age of AI?
No. What’s dying is a particular ritual version of scrum, the one where a team spends four hours estimating work that an AI tool could prototype in forty minutes.
Agile was never about points or standups. It was a bet that you learn more by shipping small and listening than by planning big. AI makes that bet stronger, because you can now ship small things faster than ever. What it breaks, however, is the machinery wrapped around the bet.
When people ask “is agile dead,” they usually mean “is my team’s process still worth the meetings?” For many teams I speak to, the honest answer is: about half of it. If you want the basics of how agile differs from older models first, read an agile vs waterfall primer, then come back here for what changes now.
What AI breaks in agile sprints in the age of AI
AI breaks three things: estimation, sprint length and velocity. All three assumed that writing code was the slow, costly part of the job.
Estimation stops meaning anything
Story points were a proxy for human effort. When an AI assistant can produce a working first draft of a feature in minutes, the effort is no longer in the typing. Instead, it’s in understanding the problem, reviewing the output and testing edge cases. As a result, two tickets with the same “3 points” can now differ by a factor of ten in review time. This is my unpopular opinion: estimation points are obsolete for any team where AI writes a meaningful share of the code.
Two-week sprints feel slow
If a feature can be built by Tuesday, a fortnight-long container creates waiting, not focus. Work finishes early, then sits until the review. So some teams respond by shrinking to one week. Others go continuous with a weekly checkpoint. Both are fine.
Velocity becomes a vanity number
Velocity rises when AI helps, and leadership loves a rising chart. But output isn’t outcome. A team can ship twice as many tickets and move no customer metric at all. As CIO.com’s piece on product management in the era of AI points out, process rituals like standups can end up overtaking the outcomes they’re meant to serve. AI makes that drift easier, not harder.
Agile in the age of AI, ceremony by ceremony: keep, change or kill
Here’s the verdict table I’d hand a product manager or scrum master today. It’s opinion, built from the teams I advise, not a law.
| Ceremony | Verdict | Why |
|---|---|---|
| Sprint planning | Change | Plan around outcomes and review capacity, not points. Use AI to draft stories and spot gaps, then humans decide scope. |
| Story point estimation | Kill | Points measured human coding effort. That’s no longer the main cost. |
| Daily standup | Change | Cut it to async updates or a 10-minute blocker check. AI can summarise status, so don’t spend meeting time on it. |
| Backlog grooming | Kill (mostly) | AI can tidy, dedupe and draft tickets. Keep a short monthly pruning session for priorities only. |
| Sprint review / demo | Keep, and make it harder | This is now the bottleneck and the quality gate. Put real users or stakeholders in front of working software. |
| Retrospective | Keep | Teams adopting AI need to talk about what’s actually working. Add AI usage as a standing topic. |
How do you use AI in sprint planning?
Use AI to prepare planning, not to run it. Agile sprint planning with AI works best when a model drafts acceptance criteria, flags missing edge cases and lists dependencies from the backlog before the meeting. The team then spends its time on the one thing AI can’t do: deciding what matters for the customer this week.
The Scrum.org post on AI in agile product teams makes a point I fully agree with: start from customer problems, then apply AI. Teams that begin with “where can we use AI?” end up with clever automation of work nobody needed.
Do sprints still make sense when AI writes code?
Yes, as a cadence for decisions, not as a container for work. Keep a regular rhythm (weekly works well) for review, reprioritising and learning. Drop the pretence that all work fits neatly into a fixed box.
A sprint example: where AI sped things up and review jammed
Here’s an illustrative sprint, a composite of patterns I keep seeing with small B2B product teams in India, not a single named client. The team was building a customer onboarding flow with three developers, one PM and one designer.
- Day 1: The PM used an AI assistant to turn call notes into user stories. It produced twelve in minutes. Four were duplicates, two described features nobody asked for.
- Days 2 to 3: Developers used coding tools to generate most of the screens and API glue. By Wednesday, nearly everything was “done.”
- Days 4 to 8: Nothing shipped. One senior developer reviewed every pull request, the designer hadn’t checked the generated UI against the design system, and QA found inconsistent error handling across screens because each was generated in a separate prompt.
- Day 10: The demo showed a flow that worked but confused users, because the copy and step order came from the AI’s guesses, not from customer conversations.
What went wrong wasn’t the tools. We planned a sprint as if coding were the bottleneck. It wasn’t. Review, design consistency and customer validation were, and nobody had budgeted time for them. So the fix was to cap work in progress by review capacity: no new ticket starts until an earlier one is reviewed and checked with a user.
Where teams miss AI: retros and user research
Most teams use AI for the obvious thing, writing code and tickets, and ignore the places it helps most: retros and user research. Hands-on Agile’s article on AI in agile product teams makes exactly this point, that teams miss AI’s use on retrospectives and user research.
I agree, with one warning. AI is good at clustering forty interview transcripts or sprint feedback comments into themes. However, it’s bad at telling you which theme matters. Use it to read more customer input than a human could, then do the judging yourself. If you want help getting the “why” across to stakeholders after that, I wrote about why building the “what” is easy but selling the “why” is harder.
On retros, add one question every sprint: “Where did AI save us time, and where did it create rework?” That single question surfaces most of the review bottleneck problems above within two sprints.
Will AI replace scrum masters and project managers?
Not entirely, but it will replace the parts of the job that are admin. Status reports, ticket hygiene, meeting notes and burn-down charts are all easy for AI to handle. CIO.com notes that AI agents are being applied to backlog, reporting and roadmap work, which is exactly this layer.
What stays is the human work: unblocking people, resolving disagreements, protecting the team from bad priorities and keeping the process honest. A scrum master who only runs ceremonies is at risk. By contrast, one who coaches the team on review capacity and customer contact is more useful than before.
It’s also worth being clear on the difference between product and project roles, since AI squeezes the project-coordination side hardest. My guide on how to ace your product management role covers what product managers should own, and 10 mistakes rookie product managers make lists the traps that get worse when output is cheap.
A lightweight setup for agile in the age of AI for a small Indian team
For a team of five to ten, I’d run a simple rhythm and keep tools boring. Indian startups often run lean with distributed or hybrid teams across time zones, so async habits are especially useful.
- Weekly cycle, not fortnightly. Monday: 45-minute planning around one or two customer outcomes. Friday: demo and retro in one session.
- Async standup. A written update in your team chat, AI-summarised if you like. Meet only when someone is blocked.
- No points. Slice work small enough to ship in one to three days. Track cycle time and review time instead.
- Review limit. Cap work in progress to what your reviewers can check that week.
- One customer touchpoint weekly. A call, a recording or a support thread, fed into planning.
- Monthly backlog prune. Thirty minutes, delete anything that’s older than a quarter and unloved.
Tools matter less than the habits. A shared doc, your issue tracker and one AI assistant are plenty. If you’re thinking about where AI value actually lands, I’ve argued before that the AI race is about owning the last mile, and for sprint teams the last mile is review and release.
What I’m changing in my advice, as of October 2026
Here’s my own update log, so you can see where my thinking has moved.
- I now tell teams to stop estimating in points if AI writes a large share of their code. Previously I’d have said “estimate less.”
- I push weekly demos over fortnightly ones, because early-finished work shouldn’t sit idle.
- I ask for a review-capacity number in every planning session. It’s the most useful figure teams hadn’t been tracking.
- I add customer evidence to planning as a standing agenda item, because AI makes it cheap to build the wrong thing.
Agile isn’t dead. It’s just no longer allowed to hide behind ceremony. So build less ritual, ship small, check with customers, and make review the thing you protect.
Frequently Asked Questions
Is agile still relevant in the age of AI?
Yes. The core ideas of short feedback loops, working software and customer contact matter more when building is cheap. What’s losing relevance is ceremony-heavy scrum, especially story points, velocity charts and long planning meetings.
How is AI changing agile and scrum?
AI is making estimation unreliable, shortening useful sprint lengths and moving the bottleneck from coding to review and validation. It also takes over admin work like ticket drafting, status summaries and meeting notes, so teams can spend time on decisions.
Will AI replace scrum masters?
It will replace much of the admin side, such as reporting and ticket hygiene, but not the coaching side. Scrum masters who help teams manage review capacity, resolve blockers and stay close to customers remain useful.
Do sprints still make sense when AI writes code?
Yes, as a rhythm for reviewing, deciding and learning, not as a box that holds all work. Many teams do better with weekly cycles and work sliced small enough to ship in one to three days.
How do you use AI in sprint planning?
Use it before the meeting to draft acceptance criteria, spot missing edge cases and flag dependencies. Keep the meeting itself for human decisions about which customer problems to solve and how much your team can review.
