In the final part of Sprint Planning, the Developers at a home-robot company's firmware team break the selected Product Backlog items into a day-by-day plan for delivering an Increment. Which Sprint Planning topic does this represent?
Select an answer to reveal the explanation.
Short Explanation
The last piece of Sprint Planning is the "how" — turning a short list of backlog items into an actual game plan for the days ahead. The Developers decompose the selected work, often into smaller pieces of a day or less, to figure out how they'll deliver a Done Increment. That plan can flex during the Sprint, but the Sprint Goal it serves does not.
Full Explanation
Sprint Planning's third and final topic is how the chosen work will get done: the Developers plan the work necessary to create a Done Increment that meets the Sprint Goal, typically by decomposing Product Backlog items into smaller units of work of one day or less. This planning is enough to get started confidently, not an exhaustive schedule for the entire Sprint - the Sprint Backlog it produces is expected to evolve as the Developers learn more. Calling this the "why" topic confuses a delivery plan with the value conversation that already happened earlier in Sprint Planning. Calling it the "what" topic misplaces it; the scope of items was already selected in the second topic, and this step is about execution approach, not about changing which items are in scope. Pushing this planning into the Daily Scrum misassigns it; the Daily Scrum inspects progress and adjusts the existing Sprint Backlog day to day, but the initial breakdown of selected work happens during Sprint Planning. Caveat: the Developers own this planning entirely - the Scrum Guide does not require any particular technique, such as story points or task-hour estimates, for decomposing the work. Operational check: by the end of Sprint Planning, the Developers should have enough of a plan to know what to start on day one, even if the rest of the plan is still emergent.