Not because Agile was wrong.
Not because Scrum was wrong.
Because the world moved, and two weeks is now a long time.
What the 2-week sprint was solving
Before we throw anything out, it helps to understand what traditional sprint cycles were actually doing well.
Discovery. Story writing. Sprint goals. Demos. Retrospectives.
These are not bureaucratic rituals. They are answers to real problems:
- What are we building and why?
- What does done look like?
- Did we build the right thing?
- What do we improve next time?
Two weeks gave teams enough runway to build something meaningful, enough frequency to course-correct before drifting too far, and enough ceremony to keep everyone aligned.
That was a reasonable answer to the constraints teams had in 2015.
The constraints changed.
What AI did to the cycle
When a story that used to take three days now takes three hours, a two-week sprint stops being a feedback loop and starts being a waiting room.
The value of a sprint is the cadence of delivery and learning. When delivery accelerates by an order of magnitude and the ceremony stays the same size, the ceremony becomes the bottleneck.
This is not a criticism of the people running the ceremonies. It is a description of what happens when the underlying assumptions of a process no longer match reality.
The assumption was that building takes most of the time. That was true. It is becoming less true every month.
What that means is that the bottleneck shifts. Discovery, planning, review, and decision-making now represent a larger share of elapsed time than they used to. The conversations your team was having every two weeks need to happen more often, faster, and with better information.
What does not change
This is the part that tends to get lost in the excitement.
UX planning still matters. User discovery still matters. Understanding what problem you are actually solving still matters. The conversations about tradeoffs, scope, and priorities still matter.
None of that goes away. In fact, it arguably becomes more important, because the cost of building the wrong thing is now much lower in effort but just as high in consequences. Scope creep and feature bloat do not slow down just because the code gets written faster. If anything, the temptation to keep adding gets stronger when shipping feels easy.
The discipline around what not to build is one of the most valuable things a team can have right now.
What I changed
I work solo most of the time, but these habits came out of thinking carefully about what actually needs to happen on a project for it to stay on track.
The backlog lives in the codebase.
Everything is tracked in docs/backlog.md, committed alongside the code. This is not a process decision. It is a context decision.
Every LLM I work with can read that file. It knows what shipped, what is in progress, and what is coming. That shared context prevents a class of mistakes that happens when the AI is building without knowing what already exists or what comes next.
A backlog in Jira or Notion does not help the AI. A backlog in the repo does.
Stories are AI contracts, not user stories.
I wrote about the full structure in I don’t write user stories. I write AI contracts. The short version: a traditional user story describes intent. An AI contract defines exactly what correct looks like before the AI starts building. Hard rules. Edge cases. QA scenarios. Verification steps.
The difference matters because an AI filling in the blanks from a vague description will fill them in wrong for anything that has domain-specific rules. A contract gives it nothing to guess.
The cycle is now one story at a time.
Here is the workflow I use:
- Write the AI contract for the story (outcome, hard rules, edge cases, QA scenarios)
- AI implements. Code review happens immediately after generation, not at the end of a sprint
- Adjustments made if needed
- Testing: automated tests from the contract scenarios, manual verification of edge cases
- PR opened, LLM review, then human review and any final adjustments
- Feature acceptance: acting as my own product owner, I sign off on it
docs/backlog.mdis updated to reflect what shipped and what changed- Merge
- The next story starts with a codebase and a backlog that both reflect what actually happened
Step 9 sounds like extra work. It is not. It is the step that keeps the AI in context for everything that follows. An AI assistant building on top of outdated knowledge will produce outdated assumptions. Keeping docs/backlog.md current is what prevents that.
The new rhythm
In practice, what replaces the two-week sprint is not no process. It is a faster, lighter version of the same questions.
What are we building next and why? Now happens more frequently, in shorter conversations, sometimes with AI helping surface tradeoffs before anyone writes a line of code.
What does done look like? Now lives in the AI contract for the story, defined before implementation starts.
Did we build the right thing? Now happens per story, not per sprint. The acceptance step is lighter because the contract already defined what correct looks like.
What do we improve? Now happens continuously, as friction surfaces during the cycle rather than being collected and addressed every two weeks.
For teams, the planning conversation becomes less about estimating work and more about deciding what comes next. AI can assist with that too: feed it the backlog, the current state of the product, and a description of what the team is trying to achieve, and it can help identify tradeoffs and surface questions worth discussing before anyone starts building.
A lot of early validation that used to require a working prototype can now happen in a planning conversation. That is one of the more underused advantages of working with AI before the code exists.
The honest takeaway
I cannot tell you what works for your team. That genuinely depends on the team, the product, the company, and how fast you can experiment.
What I can tell you is that teams treating their current workflow as fixed are going to fall behind teams that are actively experimenting. Not because the tools are magic, but because the teams willing to adapt will keep finding incremental gains until they compound into a real advantage.
The 2-week sprint was not wrong for the constraints it was designed for. The question worth asking right now is whether those constraints still apply to you.
If they do, keep the ceremony. If they do not, change it.
The only thing that is clearly wrong is not asking the question.
Is there something that has worked for your team as AI started accelerating your delivery? I would genuinely like to hear what people are finding, because I think we are all figuring this out at the same time.
This reflects how I work at stackrescue.ca on my own projects and with clients. Still refining it. If you want to compare notes or talk through how this might apply to your team, I am happy to connect.