A home-robot company runs two-week Sprints for its app team. What is the maximum length of the Sprint Planning event for a two-week Sprint, according to the Scrum Guide?
Select an answer to reveal the explanation.
Short Explanation
Think of the eight-hour cap as the ceiling for a full-length, one-month Sprint — shrink the Sprint, and Sprint Planning shrinks with it. For a two-week Sprint, the event is usually shorter than that eight-hour maximum. There's no separate fixed number the Guide hands you for two weeks specifically; it's a general "usually shorter" guideline, not a formula.
Full Explanation
The Scrum Guide sets an eight-hour maximum for Sprint Planning on a one-month Sprint and notes that for shorter Sprints, the event is usually shorter - it does not hand down a precise proportional number for every Sprint length. So a two-week Sprint's Sprint Planning is expected to take meaningfully less than eight hours, but the Guide stops short of naming an exact figure like four hours. Treating eight hours as fixed regardless of Sprint length ignores the explicit "usually shorter" guidance tied to shorter Sprints. Saying there's no maximum at all contradicts the Guide's timeboxing principle, which applies to every Scrum event, Sprint Planning included - events are timeboxed specifically so they don't run indefinitely chasing perfect detail. Naming four hours as an exact rule invents a precision the Guide doesn't state; it never publishes a linear formula scaling the eight-hour cap by Sprint length. Caveat: "usually shorter" is a guideline for planning purposes, not a number a Scrum Master can cite as an official maximum the way the eight-hour figure is official for one-month Sprints. Operational check: a Scrum Master timeboxing Sprint Planning for a two-week Sprint should set an event length well under eight hours and hold the team to whatever timebox they agree, rather than defaulting to the one-month maximum out of habit.