What factors are best considered when defining the Sprint length?

Question

Options

• AHow often team membership changes and the size of the Development Team.
• BHaving consistent Sprint length across all Scrum Teams.
• CThe level of expertise over the technology to be used, ability to release an Increment to the end

• A
  18% (9)
• B
  10% (5)
• C
  73% (37)

Explanation

Option C is correct because Sprint length should be determined by practical delivery considerations: the team's technical familiarity (less expertise = more uncertainty = shorter Sprints to reduce risk) and whether they can produce a shippable Increment within the timebox - the core purpose of a Sprint. The Scrum Guide explicitly ties Sprint length to managing complexity, risk, and the ability to inspect and adapt through a Done Increment.

Option A is wrong because team membership changes and team size are organizational concerns, not drivers for Sprint duration. Scrum expects a stable, self-managing team regardless of Sprint length.

Option B is wrong because Scrum does not require Sprint length consistency across teams. Each team chooses its own Sprint length based on its unique context; forced uniformity prioritizes coordination over delivery effectiveness.

Memory tip: Ask yourself "Can we ship?" - Sprint length is determined by how long the team needs to produce something releasable without accumulating too much risk. If the tech is unfamiliar or release cycles are constrained, shorten the Sprint to keep feedback loops tight.

No community discussion yet for this question.