After Sprint Planning ends for the app team at a home-robot company, the Developers have a Sprint Goal, a set of selected Product Backlog items, and an actionable plan for delivering them. According to the Scrum Guide, what artifact do these three pieces together make up?
Select an answer to reveal the explanation.
Short Explanation
Those three pieces bolted together — the goal, the picks, and the plan — are exactly what the Scrum Guide calls the Sprint Backlog. It's the Developers' own plan for the Sprint, made visible in real time, and it belongs to them alone. Nothing about it is a separate deliverable handed down from elsewhere.
Full Explanation
The Scrum Guide defines the Sprint Backlog as composed of the Sprint Goal, the set of Product Backlog items selected for the Sprint, and an actionable plan for delivering the Increment - exactly the three outputs of Sprint Planning. It's a highly visible, real-time picture of the work the Developers plan to accomplish, and it belongs solely to the Developers, who can update it throughout the Sprint as they learn more, as long as the Sprint Goal itself stays intact. The Product Backlog is the single, ordered source of everything that might be needed for the product overall - it's the pool the Sprint Backlog's items were drawn from, not the combination created at Sprint Planning. The Definition of Done is a quality standard describing the state a completed Increment must meet; it doesn't include the Sprint Goal or the selected items. A "release plan" isn't a Scrum Guide artifact at all - release planning can happen using Scrum artifacts, but it's not the name for what Sprint Planning produces. Caveat: because the Sprint Backlog is emergent, the plan portion is expected to change as the Sprint unfolds, while the Sprint Goal is meant to stay stable. Operational check: a Scrum Master can verify a Sprint Backlog is genuine by checking all three pieces are visible somewhere the whole Scrum Team can see, not just the list of items.