Part III. The Sprint with AI
The Sprint lasts as long as the answer takes to come back
Sprint length, short Sprints and the human clocks
Three-day Sprints
When Ramón saw the team build in one afternoon what used to take a Sprint, he proposed what seemed logical: if the work goes faster, the Sprint should too. GymApp went from two-week Sprints to three-day Sprints.
It lasted two Sprints. At the second Review, Héctor showed fourteen deliveries: the available-spots notice on the calendar, improvements to the waiting list, a new filter. Begoña asked whether the waiting list was helping new members book more. Nobody knew. The measure they had agreed on, each new member's bookings in their first month, needed at least a month.
Olga did a different calculation. In six working days, the team had spent almost one whole day in Scrum events. Celia had not been able to book a single member for an interview, because finding five willing people took her more than three days. And Germán said what everyone was thinking: they felt like they were always starting over.
Delivering is not the same as closing a Sprint
Ramón's proposal mixed up two rhythms that AI has pulled apart.
One is the rhythm of delivery: how often something new reaches production. With agents, continuous integration and automated deployment, it can be several times a day, and that is fine.
The other is the rhythm of learning and deciding: how often the team knows enough to change course. That rhythm does not depend on how fast things are built, but on how fast the answer comes back: from users, from the data and from the people who have to decide. That is the one that sets the Sprint. The Sprint lasts as long as the answer takes to come back, not as long as the code takes to write.
The Scrum Guide (in Spanish) already separates the two. A Sprint (in Spanish) lasts one month or less, and shorter Sprints serve to get more learning cycles and limit risk. But an Increment does not have to wait for the end of the Sprint to ship: it can be delivered as soon as it meets the Definition of Done, and a Sprint can hold several. With agents, the normal thing is to deliver many times within each Sprint.
The clocks AI does not speed up
The answer comes back at human pace. There are three clocks that AI barely speeds up.
The clock of whoever reviews and decides. Reviewing well takes attention, and attention runs out: reviewing is more tiring than writing (chapter 8). So is deciding. Our three agents ask me for between fifteen and twenty-five decisions a week, and I could not make twice that many well. However much the agents generate, the team moves at the pace at which its people can review and decide with judgement.
The user's clock. Finding five people for an interview takes days. Seeing whether a change alters a habit takes weeks. And the people who use the product have their limit too: an app that changes every three days is tiring (this is the cognitive cost from chapter 11).
The organisation's clock. An approval, a legal review, training the people who will use the system (chapter 16). These take time, and it is almost never the team's time.
With AI, the bottleneck is not the machine: it is these three clocks. That is why validating is exhausting, because people review at the pace the machine generates. And that is why discovering and measuring do not move at machine speed.
It depends on your context
There is no length that suits everyone. It depends on where your product is and how long it takes you to know whether something works.
A new product, still with few users, learns mainly from prototypes and conversations. The answer can come back in days. There, a one-week Sprint with daily deliveries usually works well.
A mature product, with many users and settled habits, learns mainly from how behaviour changes. An A/B experiment needs enough traffic and full weeks, because Monday does not behave like Saturday; Ron Kohavi, Diane Tang and Ya Xu explain this in Trustworthy Online Controlled Experiments (Cambridge University Press, 2020). There, the usual choice is a two-week Sprint, also with frequent deliveries inside it.
And in a regulated environment or one with high risk, approvals set the pace and it is wise not to get ahead of them (chapter 20).
Shorten when the constraints allow it
What you can do is shorten step by step. You start with a one- or two-week Sprint, depending on the context, and you shorten it when the constraints allow: when the evidence arrives before the Review, when the team reviews what it generates without a backlog building up, when the people who decide can attend and when the events take up little of the Sprint's time.
The signals for lengthening it are the opposite: Reviews without evidence, Sprint Goals that are lists of deliveries, a team that lives in planning and stakeholders who stop coming.
A three-day Sprint can be a destination. Some teams get there, with a product that gives answers in hours, users close at hand and a very good safety net. But it is a consequence of their goal and their context, never a goal in itself. If you shorten the Sprint because building is now fast, you shorten the place where the team decides, not the time it takes to know.
When the evidence arrives after the Sprint
Even with two-week Sprints, a lot of evidence arrives late. A member's first-month bookings cannot be seen in fourteen days. That is not a problem if the team knows it and organises for it.
Leading signals and outcome measures. Outcome measures (retention, revenue, first-month bookings) arrive weeks later. Leading signals arrive in days: tests with five users, which are enough to find most usability problems, as Jakob Nielsen explained in 2000; first use; whether people complete the task; errors and complaints. Each bet in the Sprint carries both, plus the date when the outcome measure will arrive.
A Review in two parts. The first: what we delivered in this Sprint and what we already know about it. The second: what the data now says about what we delivered three or six weeks ago. So as not to lose track, a bet log: what was delivered, what was expected and when it can be measured.
Knowing what moved the measure. With agents, so many changes ship that it is hard to know which one moved a number. It helps to log each change with its date, not to touch two things that affect the same measure at the same time, to test with a group of users before everyone and, sometimes, to leave alone what is being measured.
We did that last one on our website this autumn. We had changed many pages in a few days to attract more visits and more sign-ups. Before looking at the data we set what would count as success, scheduled readings at one, two, three and four weeks, and another at eight for what takes longer to show in search engines.
And for four weeks we did not touch what we were measuring, so we could attribute whatever moved. The changes shipped in a few days. The answer takes a month, and the search engines' answer, two.
What GymApp did
GymApp did not go back to two weeks: it moved to one-week Sprints. With Celia and Héctor talking to members every week, the answer from the prototypes arrived in time for the Review. They kept delivering daily. And the Review now had two parts; in the second, after four weeks, the waiting-list data finally showed up.
Ramón asked whether they would ever go back to three days. Olga answered that maybe they would, when the answer arrived in three days.
In short
The Sprint lasts as long as the answer takes to come back, and the answer comes back at human pace: that of whoever reviews and decides, that of the user and that of the organisation. Deliver as often as you can, choose the Sprint length according to your context (one or two weeks to start) and shorten it only when the constraints allow.
Three days can be a destination, never a goal. And since a lot of evidence arrives after the Sprint, the Review also looks at what you delivered weeks ago.
Try it this week
For each item in the Sprint, write down when the evidence that it worked will arrive: the leading signal and the outcome measure. If almost everything arrives after the Review, shortening the Sprint will not give you more information. If almost everything arrives before, try shortening it for three Sprints and measure with the table from chapter 17.