How a Scrum Team's work changes when AI enters the development flow.
Before this session — where is your team with AI?
Two-week Sprints were designed for a world where writing code took time. That world is gone. With AI, a feature goes from idea to working code in minutes. You don't need ceremonies for that.
Is this right? Let's find out.
Guiding question: What really changes when AI joins the team?
Scrum was designed for complex problems — where neither requirements nor solution path are clear upfront.
Scrum lives hereSprints are two-week output cycles.
Stories go in, code comes out, Demo is a checkpoint.
Velocity is the north star.
"Done" means code is merged.
No question is being answered.
Result: fast output, unknown direction.
Each Sprint starts with a Sprint Goal — a hypothesis.
The Review is a feedback session, not a demo.
Impact is the north star.
"Done" means something was learned.
Every Sprint answers a specific question.
Result: slower on features, faster on value.
The reasons Scrum was born still hold: markets shift, users surprise us, technology behaves unexpectedly.
The biggest danger for Scrum is not Waterfall, not AI — it is Scrum reduced to a meeting cadence without empiricism.
If your Sprints are answering real questions, AI makes Scrum more powerful. If they are just output cycles, AI makes the problem bigger.
Ideal for exploration and rapid prototyping. The developer stays in a creative flow — no boilerplate, no context switching.
Trade-off: high potential for technical debt and undefined behaviours at the edges.
The developer writes detailed specifications; the AI generates production-quality code. Less ambiguity, less debt.
Trade-off: requires disciplined thinking upfront — harder to start, much easier to maintain.
The AI agent runs multi-step tasks end-to-end: write, test, fix, commit. The team reviews outputs and approves decisions.
Trade-off: highest leverage, but requires mature validation practices and clear boundaries of autonomy.
AI has dramatically expanded the throughput of Delivery — what used to take weeks now takes hours.
The constraint is no longer writing code. It is deciding what is worth building — filtering demand, framing the problem, choosing what not to do.
Speed is not the problem. Strategic disconnection is — and AI amplifies it.

The logical model (Seiden) shows what connects effort to value. AI dramatically accelerates Outputs. The problem: teams celebrate output velocity as if it were outcome velocity.
Without clear Sprint Goals and Product Goals, more output just means more noise.
As the pace of delivery increases, the lag between what we ship and what we measure — user behaviour change, retention, conversion — grows proportionally.
Flying at ×17 speed without outcome signals is navigating blind. The faster you go, the more you need a compass.
The strategic outcome the team is chasing in this phase of the product.
Not a feature list. Not a project scope.
A hypothesis about impact: "If we improve retention in the first 7 days, we will reduce churn by X."
Every backlog item is evaluated against this filter before it is even discussed.
The specific question this Sprint will answer.
Not a Sprint backlog. Not a commitment to features.
A learning objective: "We believe that adding onboarding step Y will increase day-3 return rate."
The Daily Scrum asks: are we still on track to answer this question?
The three pillars: Transparency, Inspection, Adaptation.
The need for a clear Product Goal.
The value of a cross-functional, self-managing team.
Short cycles with real feedback.
Human judgment at the decision points.
Sprint length can shrink — code generation is no longer the constraint.
Daily focus shifts from progress reporting to output validation.
Refinement becomes specification work — the input to AI generation.
Review shifts from feature demo to outcome conversation.
Definition of Done must rise with output speed.
Shorter Sprints are not about moving faster. They are about learning faster — reducing the time between a hypothesis and its first real signal.
If your DoD is the same as before AI, you are accumulating invisible risk.
Shifts from progress sync to output validation and AI decision review.
Questions that matter now: Does what was generated yesterday actually meet the Sprint Goal? What decisions did the agent make that the team needs to review or override?
Shifts from feature demo to outcome conversation.
Questions that matter now: What did we learn about real user behaviour? Do the signals support or challenge the Product Goal? What should we stop building?
Shifts from process friction to human–AI collaboration quality.
Questions that matter now: Which specification practices produce the best AI output? Where is the team over- or under-supervising the agent? What validation steps are we skipping?
Becomes a hypothesis validator, not a feature approver.
The backlog is a set of bets, not a to-do list. The PO's job is to maximise the signal-to-noise ratio: which bets are worth running this Sprint?
The key skill: translating business outcomes into testable Sprint Goals.
Becomes a facilitator of human–AI learning, not a meeting scheduler.
Helps the team build the discipline to specify well, validate rigorously, and improve the collaboration loop. Removes impediments to effective supervision of AI output.
Become architects and supervisors of AI output, not prompt operators.
They design the system, write the specifications that produce quality code, review what the AI generates, and own the Definition of Done. AI executes; developers judge.
"As a user I want to receive a weekly digest so that I stay informed."
The story captures a request. It assumes the feature creates value.
It says nothing about what we will measure, or when we will stop if it does not work.
The output is a feature. Success = shipped.
"We believe that users who receive a personalised weekly digest will return 2× more often. We will test this with 20% of users in Sprint 8."
The story captures a hypothesis. It defines the outcome and the signal.
It includes a stopping condition if the hypothesis fails.
Success = learning, not shipping.
Spec-Driven Development changes the format of the specification. The shift above changes its purpose.
More ideas than ever. More stakeholder requests. More technical possibilities. The ability to filter, prioritise, and say no is now the team's most valuable — and most scarce — skill.
The Product Goal is not a planning artefact. It is the filter that protects the team from going very fast in the wrong direction.
Teams that master demand management in the AI era will build ten times more value with the same people. Teams that don't will build ten times more waste.
Scrum was not designed to produce fast — AI handles production now. What Scrum provides is a framework for learning fast: clear hypotheses, short cycles, validated outcomes.
The AI-era team that wins is not the one that ships the most. It is the one that answers the right questions fastest.
If you do one thing: write a Product Goal before your next Sprint Planning — the outcome you are chasing, why it matters now, and how you will know you succeeded.
Speed is not the problem. The problem is going very fast in the wrong direction.
Alex Ballarín · Professional Scrum Trainer · ITNOVE