Scrum in the Age of AI: Are Sprints Shrinking from Weeks to Days?

Over the last two years, AI assistants have moved into the daily work of teams. Writing code, drafting test cases, producing documentation and finding the source of a bug all take far less time than they used to. That speed raises an obvious question: if work can be produced this fast, do two-week sprints still make sense? Should sprints shrink from weeks to days?

The short answer: sprints can get shorter, and for some teams they should. But before you change anything, you need to see clearly what AI speeds up and what it doesn’t. Otherwise you will just hit the same bottleneck more often.

What AI speeds up, and what it doesn’t

Google’s DORA research programme has been looking at this question with data for two years. The 2024 DORA report found that a 25% increase in AI adoption was associated with about a 7.5% improvement in documentation quality, 3.4% in code quality and 3.1% in code review speed. The same report also observed that as AI adoption increased, delivery throughput fell by an estimated 1.5% and delivery stability by 7.2%.

The 2025 DORA report changed the picture somewhat: 90% of respondents now use AI at work, and this year AI adoption showed a positive relationship with delivery throughput. The relationship with stability, however, is still negative. The report’s main message fits in one sentence: AI doesn’t fix a team; it amplifies what’s already there. Teams with strong test automation, small batches and fast feedback win. Teams with tightly coupled systems and slow approvals push more change through the same narrow bottleneck.

What we see in the field points the same way. Most of the time between “started” and “done” is not spent writing code but waiting: for a prioritisation decision, for business sign-off, for code review, for a test environment, for another team’s dependency. AI shortens the writing; it doesn’t touch the waiting. And because more work gets produced, review and test queues can even grow longer.

What the Scrum Guide says about sprint length

The Scrum Guide defines sprints as fixed-length events of one month or less. So one-week sprints, or even shorter ones, are perfectly legitimate Scrum. The real question behind sprint length is: how often do we need to learn and be able to change direction?

A sprint is less a box for producing work and more a feedback loop. The sprint goal, the review and the retrospective make the team ask regularly: are we building the right thing, and are we building it right? As AI speeds up the work, it makes sense for that loop to run more often. But shortening the loop means speeding up every step inside it too.

Five questions to ask before you shorten the sprint

1. How many days does a work item wait today, on average? Look at your flow data: how much of an item’s total time is active work, and how much is waiting? If waiting dominates, shrink the waiting, not the sprint.
2. Can review capacity keep up with production speed? A developer with AI support can open far more changes per day than before. If code review, testing and approval still sit with the same few people, the queue grows.
3. Can the Product Owner and stakeholders decide more often? One-week sprints mean weekly priority decisions. If decision-makers are only available every two weeks, work keeps waiting no matter how short the sprint is.
4. Does your Definition of Done cover AI output? Who checks generated code for security, licensing, test coverage and readability, and how, should be defined. In DORA 2025, around 30% of respondents reported little or no trust in AI-generated code; trust is earned with explicit rules.
5. Are your events sized to the sprint? A four-hour planning session designed for two-week sprints is pure overhead in a one-week sprint. Scale the events down with the sprint length.

What changes in a shorter sprint, and what stays

What stays: the sprint goal, transparency, the review and the retrospective. They matter even more in the age of AI, because when a team produces more output it is easier to miss the question “is this output turning into an outcome?”

What changes:

• Work items get smaller. An item should be small enough to finish in a day or two. AI can help here too, by splitting large work into small, testable pieces.
• Refinement becomes continuous. Short, frequent clarification conversations instead of one long weekly session.
• The Daily Scrum focuses on flow. Instead of “what did I do yesterday?”, ask “which item on the board has been waiting longest, and how do we move it?”
• The sprint review moves closer to real user feedback. More frequent releases, more frequent measurement.

Flow instead of sprints: when to look at Kanban

For some teams the right answer is not a one-week sprint but leaving fixed timeboxes behind and moving to continuous flow. If work arrives in different sizes at unpredictable times, if the team depends on several suppliers, or if priorities are discussed with the business every day, Kanban may be a more natural fit. Instead of sprints, Kanban uses WIP limits, service level expectations and regular feedback loops.

In practice many teams combine the two: they keep the Scrum rhythm for the sprint goal and review, and manage flow inside the sprint with Kanban metrics.

The Scrum Master and the team in the age of AI

AI doesn’t make the Scrum Master’s job smaller; it shifts its focus. As note-taking and reporting get automated, the real value moves to questions like these:

• Where is work waiting, and who can resolve it?
• How does the team use AI, and which rules does everyone know?
• As speed goes up, are quality and stability holding?
• Is more output turning into more customer value?

That last question is the most important one of the AI era. The bottleneck is no longer “can we build it?” but “what should we build, and did it work?”

Our advice: measure before you shorten

If you are thinking about taking your sprints from weeks to days, we suggest this order:

1. Pull the last two or three months of flow data: cycle time, waiting time, work item age.
2. Find the longest wait and shrink it first.
3. Update the team’s rules for using AI and your Definition of Done.
4. Shorten the sprint by one step (for example from two weeks to one) and look at the data again after three or four sprints.

If you’d like to see together where your teams’ work waits, you can start with our free 360 assessment. Our approach to agile transformation is on the services page.