Two-week sprints are the default. Some teams run three weeks. Some run four. Some just work until “it’s done” and call it a sprint retroactively.

The longer the cycle, the longer bad assumptions survive. You spend two weeks building something based on a misunderstanding. The feedback comes at the sprint review. By then the team has mentally moved on. Fixing it feels like going backwards.

Shorter sprints force a different habit. You can’t fit a three-week task into a one-week sprint. So you learn to break work down into smaller pieces. That skill alone is worth the change. Teams that break work down well ship more predictably than teams that estimate well.

The real benefit of shorter cycles isn’t speed. It’s learning. You find out faster whether you’re building the right thing. You catch integration problems before they compound. You course-correct in days instead of weeks.

Try one-week sprints for a month. It’ll feel uncomfortable at first. The planning sessions will be awkward. The scope will feel too small. Push through it. Most teams that try it never go back.