Sprint length should be selected deliberately and consistently, with consideration for the nature of the project, anticipated rate of change, risk, and planned release dates. SCRUMstudy specifically identifies planned product or service release dates as a factor that should be considered when determining Sprint length.

Option B is incorrect because the expected frequency and impact of changes matter considerably. Environments with substantial uncertainty or frequent changes often benefit from shorter feedback cycles, allowing the team and Product Owner to inspect results and adapt more frequently.

Option C reverses the logic. A highly stable environment does not automatically require the shortest Sprint purely because little change is expected. Sprint length should reflect the project's context rather than follow that blanket rule.

Option D is also incorrect. SBOK guidance uses relatively short Sprint intervals and emphasizes consistent time-boxes. A universal six-week Sprint is not the recommended rule.

Once an appropriate Sprint length has been agreed upon, unnecessary variation between Sprints should be avoided because changing duration undermines historical velocity and forecasting comparability.

Study Guide reference: Initiate - > Conduct Release Planning - > Length of Sprint; Principles - > Time-boxing and Iterative Development.

========