There are many interesting discussion threads on how AI will impact agile teams. Topics range from the role of the Scrum Master, the importance of Done, the use of AI agents as teammates, to debates about story points and estimation. All of them are interesting and valuable. After all, Agile is always about change. In this blog, I want to discuss one topic: Sprint length and whether the idea of a 30-day maximum length is out of date in this new reality.
Many people are talking about daily Sprints as the new reality for AI-enabled Scrum Teams. They describe Sprint Planning at the start of the day. The Daily Scrum around lunchtime, and Sprint Review and Retrospective finishing off the day, to paraphrase the discussion.
Bob: We need to change Scrum because AI lets us do far more work and deliver more frequently.
Fred: But Scrum encourages Sprints to be 30 days or less, so what needs to be changed?
Bob: 30 days? Are you crazy? I can deliver 20 million lines of code every day. 30 days is stupid.
Of course, the debate ignores the basic idea that 30 days is an upper limit, not a lower limit, and that Sprints can, and should be the right length for your situation and organization. And they should never be longer than 30 days.
I am not going to repeat the Scrum Guide definition. That can be read here, but in a nutshell, Sprints provide the focused time a team needs to realize a goal, then evaluate it with a group of stakeholders to inform the next goal. Sprints are ultimately a planning window where work is done to help plan the next thing. Of course, the work should contribute to the product goal, which ultimately describes the value trying to be achieved. So the team is making incremental progress towards the Product Goal. The Sprint can release as much or as little as it decides is necessary to make progress towards the goal. Ideally, it releases a lot, and the Sprint Review discusses what we have learned from the increment being used by real users.
A key point is that the release process and the Scrum process are not the same thing; they run alongside each other.
Now the Scrum Team is using AI and generating a lot more ‘stuff’ every day. What does that mean for the Sprint length?
Most organizations have determined their Sprint Length on many factors, including:
Availability of stakeholders to provide feedback. A good Sprint Review requires stakeholders who have time and can provide feedback. In most organizations, stakeholders are busy and only available for a short period each week or month.
How much the team can get done that is reviewable. If, for example, release cycles and system access are constrained. It is important that Sprint Goals are valuable, which means some serious work has to happen, and for some organizations, that requires a certain length of time to pass.
Risk of wasting time or doing something stupid. At the end of the day, a Sprint empowers a team to do work against a clear goal. If that goal is wrong or may be high-risk, you might want to do less of it and present results to stakeholders more frequently. The Sprint is a learning cycle for the organization. Yes, the team will learn within the cycle, and stakeholders may as well. The formality and structure of the Sprint give learning greater visibility and the promise that feedback will influence the team's next work.
Integration into a much larger portfolio approach. For many organizations, Scrum Teams are part of a broader effort that requires Sprints to roll up into a larger review, which operates on a set cadence and structure.
Even considering all these factors for most organizations, the Sprint is two weeks. Not totally sure whether that is influenced by the above factors, or whether it is just what everyone has always done, and thus no one questions the length of the Sprint.
The Impact of AI
In my experience, AI increases the productivity of a Scrum Team. Impact varies, but at the very least, there is more stuff coming out of the team. It is logical to assume that this means larger increments and broader Sprint Goals, or shorter Sprints.
And in a perfect world, that is true. But the world is rarely perfect in large, complex organizations. If you are reducing your Sprint length or broadening the goal, consider Stakeholders, focus, value, and predictability.
Stakeholders
Are they able to provide feedback, or are they available more frequently?
I recently had this problem at Scrum.org. I created a very comprehensive curriculum for a potential new class. It was big and meaty with 6 modules and 5 lessons per module. Each lesson had 2 or 3 learning objectives, along with exercises and reference documents. It was pretty impressive if I do say so myself. I distributed it to the stakeholders prior to the Sprint Review. Got feedback during the Sprint Review. Updated the feedback very quickly and then sent it off again. Honestly, I was drowning my Stakeholders. AI enabled me to rapidly change 30 pages of text. Of course, the smart stakeholders have built AI tools to do the review. But then I started to worry that no one was actually reviewing it was just a series of AI tools changing and providing feedback. It was an AI content spiral with no governance or control. We all felt good, but honestly, the product became more mediocre.
For many Scrum Teams, Sprint Reviews and stakeholder feedback are handled haphazardly. After all, the speed of the product delivery is not so great that stakeholders can keep a handle on progress without spending a large amount of time preparing and meeting separately with the team and other stakeholders. And because humans are involved, we trust the outcome, and assuming we are all working to the same objective, issues will be highlighted. With AI, this has changed. Not only do we have more ‘stuff’ to review, but we cannot trust that the humans we trust have oversight of the work. The team and stakeholders are experiencing cognitive overload, created in part by the opportunity AI provides and the nature of its production (walls of text, interesting tangents, and a desire to do something else).
Sprint length and scope need to be considered, not for the AI capabilities but for the constraints of the humans involved.
Focus and Value
OK, let's assume we do not change the Sprint because of the productivity that AI provides. What would happen if you kept the Sprint Goal and length the same? Would it be possible to improve things around the goal, either by refining your understanding of the next Sprint, improving your general understanding of the situation and context (let's call that general research), taking time to improve product delivery workflows, or making time for training and professional development?
One fair criticism leveled at Scrum is that it encourages an almost maniacal focus on incrementally resolving goals and making progress, leaving the team very little time to do anything else. AI can improve the product's hygiene or the team's overall capability. I am reminded of a Calvin and Hobbes cartoon in which Hobbs is asked to make his bed, to which he replies, "Get me some paper and a drawing board." When asked why. He responds that he is going to build a robot to make the bed. Sometimes having time to build robots is valuable, sometimes not. AI gives us both the ability to build robots and the time to do it.
Would it make sense, given organizational constraints, to use AI to improve future work and our ability to do it? To change the balance from 80% goal oriented work to something more like 50/50?
I'm not anti-velocity, but from my observations, the first place to take advantage of AI is to make time to improve the product's operating model, while keeping the Sprint scope and length the same. This would give us the opportunity to consider challenges around governance, feedback, and innovation that increased productivity provides.
Predictability
Imagine a world where we see new tools emerge weekly that can dramatically improve our ability to deliver work. That world is not the stuff of imagination; it is the reality of our current world. I had to write a comprehensive prompt that reviews 30+ trusted sites and summarizes developments in product delivery and AI. This summary, on average, provides me with 5 things I need to look into in more detail. Every week, we are seeing changes in what works and in how effective models and agents are at performing routine tasks. This makes it harder to predict how long things will take, as our history is not representative of the future.
For most organizations, estimation is really a process of pattern matching between future work and past work. Items are sized based on how similar or different they are from previous experience. The Sprint is a container, so you refine the goal and the Sprint length based on experience. For early Sprints on a Product Goal that often requires big guesses, it is often much clearer later.
With the impact of AI, that comparison with historic work is less valuable than it once was. One solution would be to move away from estimation and focus on the most valuable Sprint Goal, timeboxing it. Then do what we can during the Sprint to deliver on that goal. If we find the Sprint Goal too easy, then we start work on the next Goal; if too hard, we learn and try not to make that mistake twice. I guess I am advocating for fewer prescriptions at the Sprint Planning event, less focus on building a complete plan, and more on setting a clear goal, getting everyone on the same page, and then planning what we should start with. So, prediction and estimation become less important in determining the length of the Sprint.
The Sprint Length is complex and, now, with AI, even harder
It is clear that AI challenges some of our preconceived ideas about Sprint Length, and those conversations are valuable. But we must remind ourselves of the three key factors for the Sprint.
Delivery - The delivery process is not the Sprint. The Sprint Review is not a phase gate for delivery. It is an opportunity for Stakeholders to review the work completed and provide feedback. Great Sprint Reviews are those where you review the increment using real usage data and experiences. If humans are involved, that needs to be factored into the sprint length.
Stakeholders - Stakeholders are busy, and gaining access to them and getting them to take the time to review the materials and provide feedback requires time. Yes, they can use AI to help, but you need to be thoughtful about where the human is in the loop.
Scope - Sprints and Increments often fit into a broader value stream. This means that having a hyperproductive team that delivers Sprints every day might be great, but ultimately just puts stress on the whole system. Before thinking about the Sprint length, you need to think more broadly about the value stream and its scope. For example, does it make sense to have 10 teams working on 1 product, each focused on a different aspect, or should there be 1 team with a much broader Sprint Goal?
The productive opportunity AI provides allows us to review not only how teams work and use Scrum, but, more importantly, what they work on. To truly realize its potential, AI requires a fundamental shift in how we view our products and services and the supporting value streams. But first, let's confirm why Sprint is the length it is.