HKSM

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?

1. Extend the sprint this time because the item has high business value.
2. Keep the sprint length fixed, negotiate scope, and consider the item for the next sprint.
3. Cancel the sprint and immediately start a new 3-week sprint.
4. 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.