Choosing a Sprint length: one week, two or four

Every new team asks the same question and most receive the same answer: two weeks. It is a reasonable default and a poor reason. A Sprint length chosen by habit tends to stay wrong for years, because nobody revisits it. The Guide gives only the outer limit, which leaves the real decision to the team, and the decision is better made with a few questions than with a coin toss.

What the sources say

The Guide's wording is short. Sprints are fixed-length events of one month or less to create consistency, and a new Sprint starts immediately after the previous one ends. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month. When a Sprint's horizon is too long, the Sprint Goal may become invalid, complexity may rise and risk may increase. Shorter Sprints can generate more learning cycles and limit the risk of cost and effort to a smaller time frame.

The SBOK® Guide defines a Sprint as a time-boxed iteration of one to four weeks. It says the length should be as short as possible to give maximum flexibility for change, while being long enough for the team to create a working deliverable that the Product Owner can review and approve. It also notes that a consistent duration helps the team forecast.

The Agile Manifesto's principle on delivery says working software should be delivered frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale. The three sources agree on direction: shorter is better, provided something worthwhile can be finished.

Five factors

1. How fast feedback can arrive. If users or stakeholders can react within days, short Sprints get that reaction used. If real feedback comes only after a monthly release cycle at the customer, a one-week Sprint will produce Increments that wait in a queue, and the extra cycles give little extra learning.

2. How uncertain the work is. The more the team is discovering, the more it benefits from short cycles. A well-understood extension of a stable product can tolerate longer ones.

3. How expensive a release or an Increment is. Some products cannot be integrated, tested and demonstrated in less than a week without heavy automation. If the cost of making a usable Increment is large, a very short Sprint spends much of its time on that cost.

4. How much time the events take. Planning, the Daily Scrum, the Review and the Retrospective have maximum durations for a one-month Sprint, and shorter Sprints have shorter events. The share of time they take stays roughly proportional under the SBOK's per-week rule, but fixed overheads, such as getting the right people into a room, do not shrink. Short Sprints feel more meeting-heavy for that reason.

5. How available stakeholders are. A Sprint Review needs the people who can say what to do next. If they can attend only once a month, a two-week Sprint will have Reviews with half the audience missing.

A sixth factor sits behind the others: the team's own stability. A newly formed team with high turnover will gain from the rhythm of short cycles. A large organisation with heavy coordination needs may have to accept a longer one.

A worked comparison

This is an illustrative case. A team of six builds a customer portal. Stakeholders can attend Reviews at any time. Releasing takes about half a day, mostly automated, and the team has a stable Definition of Done.

With these facts, one week is feasible and costs the team a lot of ceremony. Four weeks would delay feedback and risk a Sprint Goal that stops being relevant halfway through. Two weeks is the sensible middle. If the team found that Reviews produced little change, because stakeholders wanted to see more before reacting, three weeks might be tried. The SBOK allows it: a Sprint can be one to four weeks, and the Guide says only one month or less.

Now change one fact. The release process takes two days and is manual. A one-week Sprint now spends 40 percent of its time releasing, and the team would be better off either improving the release or running two-week Sprints. This is why release cost is on the list: it quietly sets a floor.

How to decide, step by step

1. Start from what the Product Owner can use. What is the shortest period in which a stakeholder can see something and respond?
2. Check the release and test cost. Can an Increment be made usable in a quarter of the Sprint?
3. Choose a length and commit to it for several Sprints. The Guide's point is consistency. A team that changes length every other Sprint cannot measure anything.
4. Review at a Retrospective. Ask whether the Sprint Goal was usually a good fit, whether stakeholders attended, and whether the cadence felt rushed or slack.

Signs the length is wrong

Too long: Sprint Goals become irrelevant during the Sprint, scope is regularly renegotiated, stakeholders ask for changes between Reviews, and the burndown is flat for a week and then falls. Too short: Reviews are thin, most Sprints end with partial work, planning feels constant, and the team spends its energy on ceremony. A change is allowed. The Guide does not prohibit it, and the right time to switch is at the end of a Sprint, with a reason the team can state.

Common mistakes

• Choosing by calendar. Aligning Sprints with a payroll month or a release train is a convenience. Check it against the factors.
• Extending a Sprint to fit unfinished work. This breaks the box and hides the real rate of progress. See timeboxing in Scrum.
• Copying another team's length. Their release cost, stakeholders and uncertainty are not yours.
• Using the shortest length as a target. The aim is learning, not frequency.

How to practise it

Write down the five factors for your team, with a number or a short note for each, and see which length they point to. In the simulator the project's Sprints are laid out in a release plan, and you can see how a different length would change what fits in each.