AI coding tools have changed the speed of development. That much is widely understood. The part nobody seems to be talking about is that when you speed up one step in a pipeline, you don’t get a faster pipeline. You get a bigger bottleneck. Let me say that again:
When you speed up one step in a pipeline, you don’t get a faster pipeline. You get a bigger bottleneck.
After rolling out AI development across my teams, I hit this wall almost immediately. The code was getting written faster. The reviews weren’t. The planning wasn’t. We optimized one part of the system and created pressure everywhere else.
That led me to a framework I call Micro-Sprints. It made me rethink the full SDLC process to match the pace that AI development makes possible.
Why Existing Frameworks Don’t Fit
If you know lean engineering, you’ll recognize the problem right away. Kanban optimizes for efficiency: keep work flowing with minimal waste. Scrum optimizes for predictability: reliable cadences and stakeholder confidence. Both are great at what they do. Neither was designed for a world where AI can compress days of dev work into hours.
AI development isn’t just a faster version of what we were doing before. It’s a paradigm shift, and it needs a new process design, not tweaks to the old one.
Micro-Sprints is still an agile Scrumban cycle at its core. It doesn’t throw out sprints or ceremonies. It compresses the parts of the SDLC that would otherwise lag behind, so the whole system speeds up together instead of one part racing ahead of the others.
The Two Bottlenecks We Had to Solve
Problem 1 — Too Much Planning
If AI doubles development velocity, you need roughly twice as much planned work to keep the team busy. At 4x, the planning burden gets huge, and worse, it becomes impossible to do accurately.
Over-planning hurts twice. First, it’s a lot of work that eats up the time the dev cycle saved. This is the same as trying to plan 8 weeks of work for a regular 2 week sprint. Second, it stretches out the feedback loop. When a sprint covers two weeks of dense work, mistakes in estimation, scope, or direction compound before anyone catches them.
The fix isn’t to plan more. It’s to plan less, more often. Smaller planning windows mean shorter feedback loops, faster course correction, and less wasted work when priorities shift.
Problem 2 — Too Much Code Review
Most teams treat AI-generated code the same as human-written code: every PR requires human review. That needs to be adjusted too, but this takes a team agreement on which parts of the app requires diffent granularity of reviews.
We added AI code review into the pipeline and it genuinely helps. It catches bugs earlier, and I’ve watched it find tricky edge cases that would have slipped through. But most companies still require human review. Either their compliance hasn’t caught up with AI or the trust isn’t there yet.
The old rule of thumb still applies… Small, frequent PRs are much easier to review than big sprawling ones. However, Since we have AI code reveiwing agents, then human code reviewers can focus on areas they expected to see the change and verification that tests were added, instead of trying to mentaly process each logic statement.
The Micro-Sprint Structure
We started with an extreme: two full sprints per week. Not because we thought it was sustainable long-term, but because it was the fastest way to break old habits.
If we had started with one-week sprints, most engineers would have just sprinkled AI onto their existing workflows. A bit faster here, a bit more productive there. That’s fine, but it’s not a paradigm shift. We needed people to fully embrace AI-first development, and the only way to do that was to make the old way impossible.
Every PR was required to have automated test coverage. Any PR marked “Needs Manual Testing” had to include a written justification, and in many cases we blocked those PRs until the validation could be automated. The release cadence only works if the pipeline is trustworthy, and a trustworthy pipeline requires automated coverage.
We were fortunate to have a strong DevOps culture at JumpCloud. Lessons from The Unicorn Project had already shaped a mature, reliable release pipeline. Without that foundation, the release frequency would have created its own bottleneck.
The Core Principles
Optimize the whole SDLC, not just the development step. A faster dev cycle creates bottlenecks elsewhere — plan for the whole system.
Smaller planning windows mean faster error correction. Compress the whole pipeline, not just the AI code creation.
Every PR needs automated coverage. Manual testing is a debt that compounds at higher cadence. Block it or fix it.
Gradual adoption of AI invites old habits to persist. An extreme initial cadence makes the mental shift unavoidable and irreversible.
What Changes vs. Traditional Scrum
| Dimension | Traditional Scrum | Micro-Sprints |
|---|---|---|
| Sprint length | 2 weeks | 2–3 days initially, then 1 week |
| Planning horizon | Sprint-length backlog refinement | Minimal, just-in-time scope |
| Code review | Human review, variable timing | Human high level + AI low level |
| Test coverage | Required, with exceptions | Automated required |
| Release cadence | End of sprint | Twice weekly → weekly |
| Feedback loop | 2-week correction cycle | 2–3 day correction cycle |
After the Experiment
After more than a month of twice-weekly sprints, we shifted back to one-week sprints. The pace had done its job. The team was genuinely operating AI-first, not just using AI tools inside old workflows.
The one-week cadence gives us flexibility the extreme cadence didn’t (incidents, on-call, holidays). The strict calendar relaxed, but the WIP discipline didn’t.
WIP Limits Stay
Each person has a WIP limit per stage. You don’t pick up three cards and start coding. You follow your card all the way to prod, and help teammates with reviews before pulling new work. Slinging a pile of code isn’t a win. It’s a bottleneck in disguise that someone else inherits.
Card Sizing — Borrowed from Kanban
We borrowed one key idea from Kanban: uniform card size. Cards should feel roughly the same weight. We still throw story points, but as a hygiene check rather than a planning tool. Cards at 3 points or under often get merged with a neighbor. Anything 8 or above gets split before it enters the sprint.
(Tangent for a future post: I’m increasingly skeptical that story points are still useful at all in an AI-augmented team. More on that another time.)
Dev + Planning Agents — BMAD
For the mechanics of AI-assisted development and planning, we use an adapted BMAD methodology. It’s a structured agentic workflow that keeps AI contributions organized and reviewable across the sprint. Worth reading if you’re building out your own AI dev process.
If you’re adapting your team’s process for AI development, resist the temptation to start slow. AI is a paradigm shift, and a shift like that needs a deliberate, uncomfortable forcing function.
Start extreme. Let the team feel the pressure. Then calibrate back from a position of genuine transformation rather than incremental improvement.
This post describes a methodology I developed and implemented with engineering teams at JumpCloud. Results will vary based on team size, product complexity, and DevOps maturity. The approach assumes a reliable, automated release pipeline. Don't skip that foundation.