A Different View of the Product Backlog
A Product Backlog does not need to be populated with fully refined user stories. In fact, maintaining an inventory of detailed PBIs is often expensive, speculative, and wasteful. Many refined items never enter a Sprint, meaning the team has spent cognitive and calendar time on work that provides no value.
Instead, treat the Product Backlog primarily as a list of candidate Sprint Goals—outcomes the team may pursue in future Sprints. PBIs and defects may still appear, but they become supporting artifacts rather than the center of gravity.
Why "candidate"? Because a Sprint Goal should only be confirmed during Sprint Planning, when the entire Scrum Team has aligned and the Developers have confidence in achieving it.
This shift pulls attention away from decomposing hypothetical features and toward articulating meaningful business and customer outcomes.
This isn’t to say that a Product Backlog can’t contain detailed PBIs, but they should be used sparingly. Defect corrections can also be in the Product Backlog and possibly be brought into Sprint Planning in addition to a candidate Sprint Goal.
Rethinking Sprint Planning
The purpose of a Sprint is to accomplish a Sprint Goal. PBIs and tasks are simply planning instruments: useful, but mutable. They may change as learning emerges.
One prerequisite to this approach is that a Sprint Goal is not a restatement of possible PBIs, but rather a business need – an objective. If you have Sprint Goals with “and” or as a list of tasks, you may need to read up on Sprint Goals. If you’re starting out with Sprint Goals, don’t use this approach.
Under this new model, Sprint Planning focuses on collaboration and business outcome. Here are the steps:
- Select the highest-value candidate Sprint Goal
- Clarify what success looks like
- Explore approaches and constraints
- Create a loose plan to achieve the goal to ensure that the Sprint Goal is possible and understood. You can use PBIs, tasks, experiments, or free format but it must be light weight.
- Adjust the candidate Sprint Goal and plan until both are aligned and the candidate is solid – an actual Sprint Goal.
The output of Sprint Planning is not "a list of refined stories." It is a committed Sprint Goal and a credible plan to accomplish it.
The focus shifts from "How do we deliver these specified items?" to "How do we achieve this goal?" This subtle reframing unlocks flexibility and encourages the team to discover optimal approaches during execution rather than constraining themselves to predetermined solutions.
Key Advantages
Efficiency: Refinement effort concentrates on work that actually enters Sprints. No more re-refining items as priorities shift or maintaining elaborate specifications for work that never materializes.
Adaptability: Without over-specified PBIs, the team retains freedom to discover the best implementation approach during Sprint Planning and throughout the Sprint itself.
Outcome focus: Candidate Sprint Goals maintain strong alignment on purpose rather than output, keeping everyone oriented toward what you are trying to achieve.
Real-time intelligence: The team's collective expertise applies when context is fresh, the full team is present, and decisions can be made with immediate feedback rather than speculative forecasting.
Reduced waste: Priorities shift. Requirements evolve. Market conditions change. The effort spent refining items three or four Sprints out is often discarded entirely.
Refinement Still Matters—But It Evolves
Backlog refinement does not disappear. It simply becomes sharp, time-bound, and outcome-driven.
What refinement addresses:
- Examine the top candidate Sprint Goals
- Discuss feasibility, constraints, and unknowns
- Break high-priority goals into a size likely achievable in a Sprint
What refinement no longer includes:
- Detailed decomposition of items into user stories
- Story point estimation for hypothetical work
- Extensive acceptance criteria for work that may never be selected
- Refinement sessions that focus on what will be delivered but not why
When refinement occurs: Instead of scheduled refinement sessions covering multiple backlog items, refinement becomes focused on business needs, expressed through candidate Sprint Goals.
Estimation shifts from guessing story points to assessing whether the top candidate goals fit into a Sprint, or whether it should be broken down even more – so called “right sizing”.
The backlog becomes a portfolio of strategic intents, not a warehouse of detailed tasks.
Managing the Transition: Common Concerns
Organizations considering this approach often surface predictable concerns. Addressing them directly accelerates adoption.
Concern: Sprint Planning becomes protracted
Without pre-refined items, Sprint Planning could devolve into extended discovery sessions where the team struggles to understand commitments.
Response: Targeted preparation for the top candidate Sprint Goal is essential. The Product Owner must articulate the goal clearly and anticipate likely questions. If Sprint Planning consistently exceeds its timebox, that signals insufficient upfront investigation—not a flaw in the model. Adjust preparation depth, not the principle.
Concern: Lack of predictability for stakeholders
Stakeholders accustomed to detailed roadmaps may perceive reduced visibility into future Sprints.
Response: Communicate at the level of candidate Sprint Goals rather than detailed features. Most stakeholders care about "When will we achieve X capability?" not "When will story #247 be completed?" A roadmap of candidate Sprint Goals provides sufficient strategic visibility without the overhead of speculative refinement. This actually improves transparency by acknowledging uncertainty rather than presenting false precision.
Concern: Product Owner cannot maintain pace
With less advance preparation, the Product Owner might struggle to be ready for Sprint Planning or to provide direction during the Sprint.
Response: This model requires an engaged Product Owner who remains close to the team and stakeholders. If your Product Owner juggles multiple teams or is frequently unavailable, this approach will expose that constraint. The solution is not reverting to extensive upfront refinement—it is addressing the Product Owner's capacity, availability, or decision-making authority.
Concern: Loss of architectural coherence
Without looking ahead, the team might make short-term decisions that create technical debt or miss opportunities for elegant solutions serving multiple future needs.
Response: Architectural thinking does not disappear—it simply does not manifest as detailed backlog items. Technical leaders should maintain awareness of the general direction (informed by the ordered list of candidate Sprint Goals) and raise architectural considerations during Sprint Planning. Some teams maintain a lightweight technical roadmap or architectural vision alongside the product backlog, ensuring strategic technical decisions remain visible without requiring detailed PBI decomposition.
Concern: Team discomfort with ambiguity
Some teams and individuals thrive with clear, detailed specifications and experience anxiety when details are deferred.
Response: This reflects maturity and trust dynamics. Start gradually—maintain more detail for technical or risky items while using lighter-weight candidate goals for better-understood domains. As the team builds confidence in their ability to determine details during Sprint Planning and throughout the Sprint, comfort with appropriate ambiguity will develop. This is a capability to cultivate, not a permanent limitation.
Considerations and Prerequisites
This approach is not universally appropriate. It works best when:
- The team deeply understands the purpose behind Scrum, not just the mechanics
- Leadership trusts empirical process control and can tolerate uncertainty
- Stakeholders are aligned on outcomes over output
- Teams possess sufficient domain knowledge and cross-functional capability
- The Product Owner can be actively engaged with the team rather than spread across multiple initiatives
- The organization operates in a context where priorities and requirements evolve frequently
It’s essential to understand that a Sprint Goal is not a restatement of possible PBIs, but rather a business need – an objective. If you have Sprint Goals with “and” or as a list of tasks, you may need to read up on Sprint Goals.
Organizations with rigid stage-gate processes, fixed-scope contracts, or deeply hierarchical approval structures may find this model incompatible with their broader operating constraints. Assess organizational readiness honestly before committing.
Conclusion
Scrum's essence is empiricism and flexibility. This model simply pushes that principle further—into strategy, not just delivery.
For experienced teams willing to challenge their assumptions about what a Product Backlog must contain and what Sprint Planning must produce, this approach can unlock significant efficiency while maintaining or improving effectiveness. The backlog becomes a tool for strategic conversation rather than administrative overhead. Sprint Planning becomes a forum for collaborative problem-solving rather than PBI selection.
The goal is not to eliminate structure, but to ensure structure serves purpose rather than constraining it.
For more, visit www.suscheck.com
