The main idea here is how backlog ordering and the Product Owner’s objectives shape the Sprint Goal. The Product Owner is responsible for ordering the Product Backlog to maximize value and to reflect the business objectives behind each item. The Sprint Goal is a short, shared objective for the Sprint that guides what the Scrum Team aims to achieve in that period. In Sprint Planning, the team selects backlog items that will help achieve that objective, with the backlog order steering which items are most important to include. So the Sprint Goal is effectively driven by the Product Owner’s business objective and the prioritized backlog, creating a direct link between what’s prioritized, what the PO wants to accomplish, and what the Sprint is supposed to deliver. The Scrum Master facilitates the process but does not set these goals, and this relationship matters for every Sprint, not just in large teams.

Understanding both what customers get today and the untapped potential guides smart next steps. Current Value shows the benefits customers are actually experiencing right now, while Unrealized Value identifies opportunities that haven’t been realized yet—needs, gaps, or features that could unlock more value if addressed. When you’re behind competitors, this combination lets you decide what to preserve and improve in the present offering, and where to invest to capture new value and close the gap. Other pairings miss one side: focusing only on what’s delivered ignores growth opportunities, and focusing only on potential without grounding it in current performance can lead to chasing ideas that don’t yet meet real customer needs. So pairing Current Value with Unrealized Value gives the clearest, most actionable view for prioritizing the backlog and shaping the roadmap.

Backlog refinement is an ongoing activity in Scrum where the Product Owner collaborates with the Developers to clarify, detail, and estimate backlog items so they’re ready for future work. This work isn’t restricted to a single event; it happens continuously, including during the current Sprint, as new information emerges or priorities change. The best choice reflects that if the team couldn’t refine earlier, they should still refine in the current Sprint to ensure items have enough detail and estimates for upcoming work. backlog refinement during the Sprint helps prepare the next increments and keeps the Product Backlog in good shape. Refinement can occur mid-Sprint, so it’s not limited to after the Sprint ends. It isn’t owned only by the Scrum Master, and waiting until the next Sprint would delay needed clarity and planning.

A Sprint Goal is created from the Product Owner’s objectives for the product and the backlog items that will deliver those objectives. When there are no Sprint Goals and the backlog items feel unrelated, it points to a lack of clear objectives from the Product Owner for upcoming Sprints. Without a defined goal to aim for, the team cannot coherently bundle and refine items to achieve a single outcome, so the Sprint Backlog ends up looking like a random collection rather than a focused set of work that delivers value in one sprint. Scrum still works well here because the missing piece is direction from the Product Owner. If the PO articulates what they want to achieve in the next sprint and how backlog items contribute to that outcome, the team can craft a meaningful Sprint Goal and select items that align with it. The other options don’t address this directional gap: Scrum itself remains applicable, empowerment isn’t the root cause of unclear goals, and cross-functionality, while important for delivery, doesn’t directly explain why a Sprint Goal can’t be formed.