Length of Sprint
A fixed time-box, usually 1-6 weeks in SBOK, during which the Scrum Team delivers a potentially shippable product increment. It is set early, kept stable for a release or project, and provides the cadence for planning, execution, review, and improvement.
Key Points
- Represents the fixed time-box for a Sprint, commonly 1-6 weeks in SBOK.
- Chosen collaboratively and recorded early, often during Release Planning.
- Stays constant within a project or release to stabilize velocity and forecasting.
- Output of Release Planning and a key input to Sprint Planning, Daily Standup, Review, and Retrospective.
- Shorter sprints increase feedback and reduce risk; longer sprints reduce meeting overhead but delay learning.
- Avoid changing the length mid-release; adjust capacity or scope instead.
Purpose
The length of sprint creates a predictable cadence for delivery and inspection. It limits work in progress, sets expectations for stakeholders, and enables empirical control of risk, quality, and value.
This time-box anchors all Scrum events and helps teams build a rhythm that improves planning accuracy and team focus.
Key Terms & Clauses
- Time-box: A hard upper limit on duration that cannot be extended once a sprint starts.
- Cadence: A regular rhythm for planning, development, review, and improvement.
- Fixed within a release: Keep the same sprint length for the duration of a release or project.
- Sustainable pace: Choose a length that the team can maintain without burnout.
- Velocity baseline: A stable sprint length supports reliable velocity and forecasting.
- Capacity vs. duration: Adjust capacity for holidays or absences, not the sprint time-box.
How to Develop/Evaluate
Selecting the sprint length:
- Assess uncertainty and risk: higher uncertainty suggests shorter sprints (1-2 weeks).
- Consider integration and lead times: complex integration or hardware may benefit from 3-4 weeks, up to 6 weeks if justified.
- Account for stakeholder availability: ensure the cadence fits review and feedback cycles.
- Balance meeting overhead: very short sprints increase ceremony frequency.
- Align across teams: use the same length to simplify coordination and dependencies.
Evaluating your choice over early sprints:
- Check predictability: compare planned vs. completed work and percent carryover.
- Review sprint goal attainment and defect trends.
- Inspect throughput and flow stability in retrospectives.
- If a change is needed, plan it at a release boundary with stakeholder agreement.
How to Use
- As input to Sprint Planning: determine capacity, slice user stories to fit the time-box, and set a realistic Sprint Goal.
- To schedule events: time-box Sprint Planning, Daily Standup, Review, and Retrospective on the chosen cadence.
- For release forecasting: calculate number of sprints per release and estimate delivery windows with velocity.
- For backlog refinement: set a cadence that ensures ready user stories before each sprint starts.
- For metrics: maintain consistent duration to keep velocity and burn charts comparable.
Example Snippet
A Scrum Team chooses a 2-week sprint for a 12-week release, yielding 6 sprints. They plan Sprint Reviews every second Friday and Retrospectives the same day.
A public holiday occurs in Sprint 3. The team keeps the 2-week length, reduces capacity accordingly, and re-slices a story to fit the time-box.
Risks & Tips
- Risk: Long sprints reduce feedback frequency and hide defects longer. Tip: Prefer shorter sprints when uncertainty is high.
- Risk: Very short sprints can cause meeting overhead and thrash. Tip: Ensure stories are small and flow is stable.
- Risk: Changing sprint length mid-release breaks metrics and expectations. Tip: Change only at a planned boundary.
- Risk: Cross-team misalignment creates coordination delays. Tip: Standardize sprint length across teams where dependencies exist.
- Risk: Ignoring calendar realities causes overcommitment. Tip: Adjust capacity for vacations and holidays, not the duration.
PMP/SCRUM Example Question
Midway through a 2-week sprint, the Product Owner asks to extend the sprint to 3 weeks to include a high-priority item. What should the Scrum Master do?
- Extend the sprint this time because the item has high business value.
- Keep the sprint length fixed, negotiate scope, and consider the item for the next sprint.
- Cancel the sprint and immediately start a new 3-week sprint.
- Switch to Kanban for this sprint to accommodate the urgent item.
Correct Answer: B — Keep the sprint length fixed, negotiate scope, and consider the item for the next sprint.
Explanation: The sprint time-box should not be extended once started. Handle urgent scope by reordering the product backlog or adjusting scope, and only revisit sprint length at a planned boundary.
HKSM