·2 min read

Why I stopped planning sprints

I ran sprint ceremonies for years. Planning, standups, the whole ritual. The rhythm made sense when shipping took days and coordination was the hard part.

Then I started shipping features in hours instead of days. With a clear spec and Claude Code, the gap between "I know what to build" and "it's in production" collapsed. Two-week sprints became a structure around a problem that no longer existed.

So I stopped. I dropped story points and velocity tracking along with them.

What replaced it is simpler: pick the most important thing, write a spec, ship it, repeat. The constraint is clarity, not time. If I know exactly what to build, I build it fast. If I don't, no amount of planning ceremonies will help.

This only works for solo builders or very small teams. If you're coordinating ten engineers, sprints still solve a real problem: synchronization. But for one person with AI leverage, the planning overhead exceeds the execution time.

I still reflect. Every Friday I look at what shipped and what I learned. Twenty minutes with a notebook, not a ninety-minute retro with sticky notes.

The cadence shifted from plan-execute-review to execute-review-execute. The planning happens in the spec, not in a calendar event.