SkarpChapter 16 of 21
Product Backlog Management in Practice: Estimation, Ordering, and Adaptation
Observe how a Product Owner and Scrum Team refine, estimate, and reorder Product Backlog items as they learn, and examine how Product Goal and Sprint Goals guide these decisions.
From Product Goal to Product Backlog: Setting the Direction
Why Product Goal Matters
The Product Backlog only makes sense when you see it as a way to move toward a clear target: the Product Goal, a future state of the product the Scrum Team plans against.
Canonical Definitions
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It changes as the Scrum Team learns; it is not a fixed contract or full upfront plan.
Roles and Backlog
The Product Owner maximizes value by managing and ordering the backlog. Developers bring implementation insight. The Scrum Master helps everyone apply Scrum and empiricism correctly.
Empiricism in Backlog Work
Empiricism means transparency (visible backlog and Product Goal), inspection (regularly examining items, estimates, and value), and adaptation (reordering as new information appears).
Exam Signal
If an exam option claims the Product Backlog is fixed after initial planning, or that Developers alone own it, that contradicts the current Scrum Guide and should raise a red flag.
Who Does What? Collaboration vs Accountability
Accountability vs Collaboration
The Product Owner is accountable for ordering the Product Backlog, but they collaborate with Developers and stakeholders for information. Collaboration does not change accountability.
Product Owner Focus
The Product Owner is accountable for the Product Goal, for maximizing value, and for the ordering of the Product Backlog based on value, risk, and other factors.
Developers' Role
Developers estimate work, explore feasibility, and refine items. They influence ordering via their insights but do not own the ordering decisions.
Scrum Master Support
The Scrum Master coaches and facilitates, helping the team use empiricism and sound collaboration, but does not take over Product Backlog ordering.
Typical Exam Trap
Be wary of options that say Developers or stakeholders own the Product Backlog order, or that the Scrum Master orders it. Those conflict with the Scrum Guide.
Refinement in Practice: Making PBIs Ready Enough
What Is Refinement?
Refinement is ongoing work where the Scrum Team breaks down and clarifies Product Backlog items so they are small, clear, and better understood. It is not a formal event.
Continuous and Collaborative
Refinement happens throughout the Sprint and is collaborative. The Product Owner and Developers work together; stakeholders may join when useful.
Key Activities
Typical actions: clarify value and outcomes, agree on acceptance criteria, split large items, estimate effort, and discuss dependencies and risks.
Definition of Done Link
Refinement aligns each item’s expectations with the Definition of Done, the formal description of the state of the Increment when it meets required quality measures.
Exam Clues
Beware of statements that refinement is limited to Sprint Planning, owned only by the Product Owner, or fixed at a specific percentage of the Sprint time.
Estimation Basics: Purpose, Not Precision
Why Estimate?
In Scrum, estimation supports forecasting, helps the Product Owner make ordering decisions, and reveals misunderstandings. It is not about perfect precision.
Who Estimates?
Developers typically estimate, because they do the work. The Product Owner clarifies scope but should not impose or override Developers’ estimates.
Techniques Are Optional
The Scrum Guide does not require story points, Planning Poker, or any specific method. Teams may choose techniques that support transparency and learning.
Estimates Are Not Commitments
Estimates are approximate and may change as the team learns more. They should never be used to punish or compare individuals.
Exam Trap
If an option says Scrum mandates a particular estimation technique or unit, it is inconsistent with the current Scrum Guide and likely incorrect.
Estimation and Re-estimation: A Worked Scenario
Scenario Setup
A Scrum Team builds a mobile banking app. Product Goal: customers can do 90% of common banking tasks in the app without visiting a branch.
Initial Estimates
Developers estimate PBIs: view balances (1), own‑account transfer (2), international transfer (8), mortgage pre‑approval (13+). Larger items are riskier.
Initial Ordering
The Product Owner orders by value vs effort: 1, 2, 3, 4, focusing first on everyday tasks that strongly support the Product Goal.
New Information
Stakeholders say international transfer is critical. Developers find a reusable integration, reducing effort for PBI 3. They re‑estimate it from 8 to 5.
Adaptation
With higher value and lower effort, the Product Owner reorders to 1, 2, 3, 4. This adaptation of the Product Backlog is empiricism in action.
Ordering Techniques: Value, Risk, Dependencies, and More
Ordered, Not Random
The Product Backlog is ordered, but Scrum does not prescribe a specific method. The Product Owner chooses how to order, guided by value and other factors.
Key Ordering Factors
Common factors: value, risk and uncertainty, dependencies, urgency or deadlines, and cost or effort. The Product Owner balances these.
Value and Risk
Sometimes you order by pure value; other times you bring risky items earlier to learn quickly. Both can be Scrum‑consistent.
No Mandatory Frameworks
Scrum does not require WSJF, MoSCoW, or any scoring system. These are optional tools, not part of the framework itself.
Exam Signal
Beware of rigid rules like "must be ordered by business value only". Look for answers where the Product Owner balances multiple factors.
From Product Goal to Sprint Goal: Using the Backlog as a Bridge
Three Levels of Direction
Product Goal = long‑term destination. Sprint Goal = single objective for this Sprint. Increment = concrete stepping stone toward the Product Goal.
Backlog as a Bridge
The Product Owner orders the Product Backlog as an evolving route from the current product toward the Product Goal, informed by learning each Sprint.
Sprint Planning Link
In Sprint Planning, the team selects PBIs and crafts a Sprint Goal that expresses why the Sprint matters and how it advances the Product Goal.
Sprint Backlog Definition
The Sprint Backlog contains the Sprint Goal (why), selected PBIs (what), and an actionable plan (how) for delivering the Increment.
Exam Clues
Look for Sprint Goals that clearly support the Product Goal. Multiple Sprint Goals per Sprint or goals unrelated to the Product Goal are anti‑Scrum.
Adapting the Product Backlog to New Information
Learning Platform Scenario
A Scrum Team builds an online learning platform. Product Goal: launch a basic yet delightful platform for students by next academic year.
New Regulatory Requirement
A security incident leads the university to mandate two‑factor authentication. The Product Owner adds a 2FA PBI and moves it near the top due to urgency.
New Sprint Goal
Next Sprint Goal might be: "Increase account security for student access", with PBIs centered on 2FA and related security work.
Changing Estimates
Live chat was estimated as small, but new privacy and moderation needs make it large and risky. Developers re‑estimate based on this new information.
Ordering Choices
The Product Owner may keep live chat high to learn early, or move it down if it is not essential. Both can be Scrum‑consistent, depending on the Product Goal.
Quiz 1: Roles, Refinement, and Estimation
Test your understanding of who does what in Product Backlog management.
During Product Backlog refinement, the Scrum Team discusses a large, unclear item. Who is accountable for deciding its final position in the Product Backlog after Developers have clarified and estimated it?
- The Scrum Master, because they facilitate the process and ensure Scrum is followed
- The Product Owner, after considering input from Developers and stakeholders
- The Developers, because they understand the technical complexity best
- Key stakeholders, because they provide the budget and business priorities
Show Answer
Answer: B) The Product Owner, after considering input from Developers and stakeholders
The Product Owner is accountable for maximizing the value of the product and for ordering the Product Backlog. Developers provide estimates and technical insights, stakeholders provide business input, and the Scrum Master facilitates, but none of them replace the Product Owner’s accountability for the final ordering decision.
Quiz 2: Adapting Estimates and Backlog Ordering
Check how you reason about changing estimates and new requirements.
Mid‑Sprint, Developers discover that a Product Backlog item planned for a future Sprint is much more complex than they thought. They re‑estimate it as significantly larger. What is the most Scrum‑consistent next step?
- Lock the original estimate, because changing estimates would reduce predictability
- Ask the Scrum Master to remove the item from the Product Backlog until the complexity is resolved
- Have the Product Owner consider the new estimate and adjust the Product Backlog ordering if needed
- Immediately cancel the current Sprint so the team can replan the Product Backlog
Show Answer
Answer: C) Have the Product Owner consider the new estimate and adjust the Product Backlog ordering if needed
Scrum is founded on empiricism, so learning that an item is more complex is valuable information. Developers can change the estimate, and the Product Owner should use this new information to reconsider the item’s ordering. There is no need to cancel the Sprint, and removing the item entirely or freezing estimates would reduce transparency and adaptability.
Thought Exercise: Ordering Under Constraints
Work through this mental exercise to practice ordering decisions.
You are the Product Owner for a campus events app. Your current Product Goal: "Students can easily discover, register for, and get reminders about campus events from a single mobile app."
You have the following Product Backlog items (all are well‑refined and similarly sized according to Developers):
- A. "Search events by keyword"
- B. "Push notifications for event reminders"
- C. "Filter events by faculty/department"
- D. "Anonymous feedback on past events"
New information:
- The university’s marketing team says students often forget events they signed up for.
- A pilot group of students says they struggle to find events relevant to their department.
- The next academic fair is in 6 weeks; leadership wants better turnout.
Your task (no single right answer, but some are more Scrum‑aligned):
- Order these four PBIs based on the Product Goal and new information.
- Write a possible Sprint Goal for the next Sprint using two or three of these items.
- Explain briefly why your ordering supports the Product Goal.
Reflect after you decide:
- Did you consider value (event turnout and student satisfaction)?
- Did you consider urgency (academic fair in 6 weeks)?
- Would your Sprint Goal be a clear, single objective?
For PSM I, practice explaining your reasoning in plain language like: "Given our Product Goal and the need to improve turnout soon, I would order B, C, A, D and choose a Sprint Goal focused on reliable reminders for registered events." This style of reasoning often matches the best exam options.
Key Terms and Concepts Review
Flip these cards to reinforce core definitions and relationships.
- Product Backlog
- The Product Backlog is an emergent, ordered list of what is needed to improve the product.
- Product Goal
- The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against.
- Sprint Goal
- The Sprint Goal is the single objective for the Sprint.
- Increment
- An Increment is a concrete stepping stone toward the Product Goal.
- Sprint Backlog
- The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).
- Definition of Done
- The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
- Who orders the Product Backlog?
- The Product Owner is accountable for ordering the Product Backlog, while collaborating closely with Developers and stakeholders for input.
- Who estimates PBIs?
- Developers typically estimate PBIs, since they do the work. The Scrum Guide does not prescribe a specific estimation technique.
- Can the Product Backlog change during a Sprint?
- Yes. The Product Backlog is emergent and can change at any time as the Scrum Team and stakeholders learn.
- Empiricism in backlog management
- Scrum is founded on empiricism and lean thinking. For backlog management this means making work transparent, inspecting it frequently, and adapting ordering and estimates as new information appears.
Exam Patterns: Spotting Scrum-Consistent Answers
Scrum-Consistent Themes
Look for answers that stress empiricism, clear accountabilities, a single Sprint Goal, and strong links between Product Goal, Sprint Goals, and the Product Backlog.
Challenging Distractors
Question any option that freezes the Product Backlog, forbids changing estimates, or assigns Product Backlog ordering to anyone other than the Product Owner.
Artifacts in Harmony
Remember how artifacts fit: Product Backlog (emergent route), Sprint Backlog (current Sprint plan), Increment (usable step toward the Product Goal).
Using Course Tools
Your diagnostics, mock exams, and gap guides will show which backlog topics you need to revisit. Use them to target practice on tricky scenario questions.
Next Study Move
As you review, try to explain scenario answers in plain Scrum terms: who is accountable, what changed, and how empiricism guides the right adaptation.
Key Terms
- Scrum
- Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
- Sprint
- Sprints are the heartbeat of Scrum, where ideas are turned into value.
- ordering
- The act of arranging Product Backlog items in a sequence that reflects the Product Owner’s current best understanding of value, risk, dependencies, urgency, and other factors.
- Increment
- An Increment is a concrete stepping stone toward the Product Goal.
- Developers
- Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.
- Scrum Team
- The Scrum Team is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
- empiricism
- Scrum is founded on empiricism and lean thinking.
- estimation
- The activity, usually done by Developers, of approximating the effort or complexity of Product Backlog items to support forecasting and ordering.
- Sprint Goal
- The Sprint Goal is the single objective for the Sprint.
- Product Goal
- The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against.
- Scrum Master
- The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide.
- Product Owner
- The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.
- Sprint Backlog
- The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).
- Product Backlog
- The Product Backlog is an emergent, ordered list of what is needed to improve the product.
- Definition of Done
- The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
- Product Backlog refinement
- Ongoing collaborative work in which the Scrum Team breaks down and further defines Product Backlog items so they are smaller, clearer, and better understood.