Two weeks is the sprint length almost nobody chose on purpose. It is the default in most tools, the number the last team you worked on used, the answer you give when someone asks and you have not thought about it lately. And two weeks is a genuinely good default. But "we never picked it" is a poor reason to keep any cadence, because sprint length is one of the few dials that changes how your whole team feels week to week.
So it is worth actually deciding. The good news is the decision is bounded, and the trade-off underneath it is simple once you name it.
What the Scrum Guide actually says
Less than people assume. The Scrum Guide, the official definition of Scrum maintained by its creators, fixes one thing: a sprint is one month or less. That is the entire rule. It does not say two weeks, it does not rank the options, it leaves the specific length to the team.
The reasoning behind the cap is worth keeping in mind, because it is the same reasoning that should drive your own choice. Go much beyond a month and the sprint goal can quietly go stale, complexity piles up, and you have gone too long without stopping to inspect where you really are. Shorter sprints, the guide notes, generate more learning cycles and keep the cost of a wrong turn small. That last idea is the whole game.
The real trade-off
Every sprint length is a bet between two things pulling in opposite directions.
Shorter sprints buy faster feedback. You finish, show real work, learn something, and adjust, sooner. A wrong assumption costs you a week instead of a month. For a young product still figuring out what to build, that speed is worth a lot.
Longer sprints buy less overhead. Planning, review and retrospective happen once per sprint whether the sprint is one week or four. Run one-week sprints and those ceremonies eat a real slice of every week. Run four-week sprints and the same meetings are a rounding error, but you wait a month to course-correct and the plan has more time to drift from reality.
That is the tension. Everything else is detail.
Matching the length to the team
With the trade-off named, the options sort themselves:
- One week. Best for support and operations teams, very early-stage products, or anyone who thrives on tight feedback. The catch is discipline: stories have to be small enough to land in five days, and your ceremonies have to stay short or they will dominate. If you have not kept your standups genuinely brief, a one-week cadence will expose it fast.
- Two weeks. The default for good reason. Long enough to finish stories of a meaningful size and keep ceremony overhead modest, short enough to catch a mistake before it compounds. If you are unsure, start here.
- Three to four weeks. Suited to work with long lead times, deep research, hardware, or heavy dependencies, where two weeks would leave you with nothing finished to show. The risk is drift, so it leans harder on strong mid-sprint check-ins to stay honest.
Consistency beats the perfect number
Here is the part that matters more than the choice itself: keep the length the same. Velocity, the number you use to plan future sprints, only means anything if your sprints are the same size. Swap between one, two and three weeks and you cannot compare one sprint to the next, and your burn-up chart and velocity lose their footing.
Pick a length, run it for at least three or four sprints, and give it a fair trial before you judge it. One rough sprint is not evidence; it is a Tuesday.
How to change it, when you should
If the length is genuinely wrong, if work keeps spilling over, or ceremonies feel relentless, change it. Just change it deliberately, at a boundary, not in a panic halfway through. The retrospective is exactly where this decision belongs: the team names the pain, agrees on a new cadence, and commits to trying it.
In Scrumpy the sprint length is a team setting, so you set your default once and it is prefilled every time you start a sprint, up to that one-month cap. Change it in one place and the next sprint picks it up. The mechanics take ten seconds. The thinking, the honest look at whether your cadence is serving the team or just surviving from habit, is the part worth doing at all. Do that much, and whichever number you land on will be one you actually chose.
Frequently asked questions
How long should a sprint be?
For most teams, two weeks is the best default. It is short enough to get feedback quickly and correct course, but long enough that the planning, review and retrospective do not eat a large share of every sprint. One week suits fast-moving or support-heavy work; three to four weeks suits work with long lead times. The exact number matters less than picking one and keeping it consistent.
What is the maximum sprint length?
The Scrum Guide sets the maximum at one month or less. Beyond that, the sprint goal can drift, risk builds up, and you go too long without inspecting real progress. Within that cap the Scrum Guide does not prescribe a length; the team chooses what works for them.
Are one-week sprints too short?
Not necessarily, but they carry more overhead. With a one-week sprint you plan, review and retrospect every five working days, so ceremonies take a bigger slice of your time and stories must be small enough to finish fast. They work well for support teams, early-stage products, or any team that benefits from very tight feedback loops.
Can I change my sprint length?
Yes, and the retrospective is the place to decide it. If sprints keep spilling over or ceremonies feel too frequent, adjust the length and try it for a few sprints before judging. The one rule is to change it deliberately between sprints, not mid-sprint, so your velocity stays comparable from one to the next.
