The hard part of Scrum in the age of AI
2026-10-01
Even with AI as far along as it is now, I do not think Scrum has lost any of its value. If anything, it feels like it matters more than ever.
That said, if you try to run Scrum exactly the way you did before AI came along, some parts of it honestly start to hurt.
To put the conclusion first: now that development has gotten this fast, I think every piece of Scrum — sprints, milestones, all of it — needs to be cut smaller than before.
If you do not keep a clear rhythm, things go slack fast, goals get blurry, and you end up being chased by Scrum instead of building a good product.
So this time I want to write down what I have been feeling lately as a scrum master.
The product backlog matters more than ever
It goes without saying that the product backlog is the lifeline of a project in Scrum.
Which is exactly why the product owner, who is accountable for managing it, can make the difference between a team running at full strength and a team that is not.
With AI, developers have gotten dramatically faster.
Product owners, on the other hand, have not gotten that much faster at their own job.
Product backlog items in particular are hard to write unless the user stories behind them are clear.
In other words, the whole Scrum team, starting with the product owner, now has to get to a concrete picture of the final product faster than ever before.
The product owner becomes the bottleneck more easily than ever
I am repeating myself, but the speed AI has given developers puts more pressure on product owners than they have ever had.
Writing product backlog items is the product owner's responsibility, but they do not have to do all of it alone.
The Scrum Guide itself says that work can be delegated to others.
Even so, I have seen plenty of product owners who never delegate and end up carrying all of it by themselves.
When someone is new to the product owner role, this is where the bottleneck forms more than anywhere else.
For example, if the developers do not have a solid picture of the final product either, it gets hard for them to step up and write backlog items on their own.
In those cases, going back over the inception deck or running refinement more often to build up a shared understanding bit by bit is what matters — and honestly, that is one of the fun parts of agile.
But every now and then it is the product owner who does not have a clear picture, and that one is genuinely tough.
Whether it is agile or waterfall, you cannot move development forward when the product backlog items — in other words, the specs — are not clear.
A product owner with a fuzzy picture getting buried in backlog writing, and the team turning out low-quality increments as a result, is about as bad as it gets.
There is no longer time to grow people
A Scrum team should work as one team, and when the product owner is struggling, the scrum master should be the one leading the effort to improve how that work gets done.
I do not think the scrum master role itself has changed much since AI showed up.
What has changed is the pace. How often I need to keep an eye on things, and how quickly I need to escalate, have both clearly gone up.
Still, when the product owner simply does not have the skills yet, there is honestly a lot that cannot be helped.
Back when development was slower, there was time to grow a product owner properly while the work moved along.
Now, to be honest, even that time is gone.
And this is not only about product owners.
As development has sped up, developers are also expected to take part in writing product backlog items, so what each person is expected to cover has gotten wider.
It used to be fine to have a few people on the team who did not want to touch the backlog. Now, just having one of them makes the team noticeably harder to run.
Ideally, I would build the team out of people who approach Scrum with a positive attitude.
But at a small startup, most of the time you do not get to choose who is on the team.
I have always run study sessions, and I work on this in retrospectives and 1-on-1s too, but if you ask me whether it is working, honestly, I do not feel much of a response.
No longer having time to grow people — that might be the part of Scrum in the age of AI that I find hardest.
Cut things small and keep the rhythm
On the other hand, there are things you can do.
Now that developers can get through backlog items faster than before, the product backlog needs to be filled more actively than before.
And that means the product owner needs to hold a concrete picture of the product over a longer horizon, and make sure that picture sinks in with the developers.
Put more into refinement
The first thing, I think, is to spend more time on refinement than before.
Breaking work down into tasks can now be handed off to AI, so the "how" part of sprint planning actually takes less time than it used to.
The "why" and the "what", on the other hand, still take just as long to align on.
If you settle those in refinement ahead of time, sprint planning should fit inside its timebox.
That said, my own team has not actually managed this yet.
Honestly, it comes down to the product owner not fully understanding what refinement is for.
Cut milestones smaller
Next, if you split your product goal into milestones, the scope of each milestone needs to be cut smaller than before.
If milestones stay coarse, each one ends up needing too many product backlog items.
Then the user story mapping you do per milestone gets coarse too, it takes far too long, and in the meantime the developers burn through the whole backlog.
Cut milestones small, and at each boundary, revisit the inception deck — add the questions that were missing, and redo it if the purpose has drifted.
Then do the user story mapping. I think that is roughly the rhythm you need.
But this one has not happened yet either, because the product owner has not really taken in the idea of milestones.
Make sprints shorter
Last, I think sprints should be even shorter.
With development this fast, a long sprint is very likely to end up with a bloated, blurry sprint goal.
I also do not think a single sprint retrospective should have that much to look back on.
My team runs one-week sprints every time, and I feel it works well.
The sprint goal stays narrow so the purpose does not blur, there are more retrospectives so improvements come faster, and stakeholders get to check things sooner so there is less rework.
It depends on the situation, of course, but personally I find even two weeks too long, and I see almost no upside to it.
It all comes back to the product owner
In the end, two of the three things you can do depend on the product owner understanding them.
And not having time to grow that understanding is exactly the hard part I wrote about earlier.
Still, if you look at it positively, agile gets even more agile, and you can improve far more often, so the team's growth curve as a Scrum team should be able to climb steeply.
Well, that is the ideal version of it, anyway.
That is a rough write-up of what I have been feeling while watching Scrum lately.
The 2020 Scrum Guide was written before AI got this deep into development, so it says nothing about AI.
But the Scrum Guide is intentionally incomplete to begin with, and it leaves how to handle each situation up to the team.
What hurts is not the Scrum Guide, and the things you can do are all there inside it.
It is just that AI has taken away the time it takes to grow people who can actually make those things work.
How to get past that is probably exactly where a scrum master's skill gets tested.
And if I could ever get agile running the way it is supposed to, I truly think it would be a lot of fun.