Agile practice in the AI era: what really changes for Scrum and Kanban
How sprint planning, refinement, retros, Definition of Done and WIP limits change once AI-assisted development becomes normal – and where new bottlenecks appear.
AI doesn't make agility obsolete – it forces the practices to adapt. The interesting question is rarely „does AI replace Scrum?“ but: where do bottlenecks shift, which rituals stay valuable, which need an update? A pass through the core elements from a PO and team perspective.
Sprint Planning: estimates under new conditions
Story-point estimates often still rely on mental models from a pre-AI era. Teams underestimate what is actually possible – or overestimate it when they trust AI output uncritically. Both errors are expensive, just in different ways.
It helps to break the estimate down: how much effort sits in understanding, in implementation, in review, in tests and integration? AI mostly shifts the implementation share; the others stay or grow. Velocity as one number loses that differentiation. Cycle time per story class is more honest.
For planning: less trust in „this is how much we always ship“, more in „this is how long understanding, building and review typically take for stories of this shape“.
Refinement: AI helps structure, not understand
An assistant pre-structures stories, proposes acceptance criteria, raises open questions. That saves time in pre-refinement. What can't be replaced is the actual clarification: shared understanding in the team, drawing out edge cases, aligning technical options with functional priority.
Refinements get shorter, denser, more focused on content. Preparation matters more, because less „thinking on the spot“ happens in the meeting itself. The PO shifts towards curation – someone who contextualises AI suggestions and keeps focus on the important questions.
Retrospectives: new reflection questions
Retros gain new topics. Where did AI actually help this sprint? Where did it cost time because a plausible but wrong suggestion had to be dug back out of the code? Where did friction arise because team members work with AI at different intensities and expectations collided?
Team dynamics is underrated. When one person visibly pushes through more stories with AI support while others work more classically, perception gaps appear – „why is it slower for me?“, „why is my quality discussed more than the others' volume?“. Naming these openly is retro work at its best.
A useful default question: did we blindly accept AI suggestions this sprint that might bite us later? Sounds harmless, prevents many silent construction sites.
Definition of Done: AI-specific checkpoints
When AI produces code, the Definition of Done must stay consistent: quality matters, not origin. Things that used to be „obvious“ often need explicit wording now. Was the generated code understood? Are tests meaningful or just syntactically green? Were security aspects, rate limits and error paths considered, which a model tends to ignore?
Some teams extend their DoD with a line like „AI-generated code was read by at least one person and its consequences were evaluated“. Sounds trivial, prevents the entire class of errors that appear when suggestions get waved through because „it compiles“.
Kanban and WIP: bottlenecks move
The most important structural effect: faster development moves the bottleneck, often towards review, QA, approvals or deployment. A team that speeds up implementation without adjusting the rest mostly produces more tickets stuck in review – not more value in the product.
For Kanban: WIP limits need re-calibration. Where „in progress“ used to be the bottleneck, „in review“ or „awaiting approval“ often is now. Failing to manage those columns actively just moves wait time elsewhere in the value stream.
QA changes too. When code is produced faster than classic verification can keep up, QA has to enter earlier. Test automation becomes more critical; exploratory testing stays important but gets more targeted. Otherwise you end up with a team that delivers faster – and releases slower.
Scrum Master and coaching focus
The focus of the Scrum Master shifts. Classically: remove impediments, reflect on process, enable the team. New: healthy use of AI tools. How do we prevent two classes of team members – those who use AI heavily and those who avoid it? How do we stop „the AI suggested it this way“ from becoming an excuse for unclear requirements?
Balance between speed and reflection. AI seduces you into „let's quickly try something else“. Without conscious pauses, critical reviews and structured retros, you get activity without insight – the classic „delivered a lot, understood little“.
Takeaway
AI doesn't replace agile practice. It needs to be recalibrated: different models in planning, denser refinements, new default questions in retros, more explicit Definition of Done, re-tuned WIP limits, and a different emphasis in the Scrum Master craft. The bottleneck moves from pure development speed to decision quality, review and release. Ignore that shift and you lose the very effects AI is supposed to unlock.