FIT2002 Chap.8 Product Backlogs and Sprint Planning
Product Backlogs and Sprint Planning
Product Backlog management makes future product options visible and ordered. Ordering is not a permanent ranking produced by one formula; it reflects value, risk, dependency, learning and the Product Goal. Refinement adds useful detail, size and clarity so that the most relevant items can support upcoming decisions.
Relative estimates compare effort, complexity and uncertainty but do not promise calendar duration.
Sprint Planning asks why the Sprint is valuable, what can be Done, and how the selected work will be created. The resulting Sprint Goal gives coherence while Developers form and adapt the Sprint Backlog. A Scrum board can make workflow visible, but movement across columns is not proof of value or quality.
Strong answers connect an ordering decision to evidence, preserve capacity and quality constraints, and state what new information should trigger reordering.
What this chapter covers
- 01
Product Backlog as an emergent ordered list of product options
- 02
Ordering by value, risk, dependency, learning and Product Goal
- 03
Backlog refinement as an ongoing clarification and sizing activity
- 04
Relative estimation for effort, complexity and uncertainty comparison
- 05
Sprint Planning through why, what and how decision questions
- 06
Sprint Goals as coherent value objectives rather than task inventories
- 07
Scrum boards and work-in-progress visibility without false certainty
Worked example · free
Order a backlog and form a coherent Sprint Goal
- +2Place identity verification early because it addresses major compliance exposure and enables the recommendation experiment's data dependency.
- +2Select payment receipt because it has broad pilot-user value and fits with identity verification within the 18-point forecast.
- +1The selected 13 points leave capacity uncertainty visible; do not add work merely to consume the forecast number.
- +2Defer the dependent recommendation experiment until verified data exists, and leave low-value colour work below stronger options.
- +2Write a goal such as 'Make pilot transactions trustworthy and auditable through verified identity and user-visible receipts.'
Key terms
- Product Backlog
- An emergent, ordered list of what may improve the product. It is the single source of work undertaken by the Scrum Team and changes as evidence and context evolve.
- Backlog Refinement
- The ongoing activity of breaking down and further defining Product Backlog items by adding detail, order and size. It supports readiness but is not a formal Scrum event.
- Sprint Goal
- The single objective for the Sprint that explains why the work is valuable. It provides coherence and flexibility in the exact work needed to achieve it.
- Sprint Backlog
- The Sprint Goal, selected Product Backlog items and the actionable delivery plan. It is created by and for Developers and is updated as more is learned.
- Relative Estimation
- Comparison of work items against each other using perceived effort, complexity and uncertainty. It supports forecasting but is not a conversion guarantee to hours.
- Scrum Board
- A visual representation of work states used to improve transparency and coordination. Its columns should reflect useful workflow rather than become a substitute for product and quality evidence.
Product Backlogs and Sprint Planning FAQ
Who decides the order of the Product Backlog?
The Product Owner is accountable for effective Product Backlog management, including ordering. Good ordering still draws on stakeholder input, technical knowledge, risk evidence and Developers' understanding. Accountability does not mean making every judgement alone. The order should remain transparent and adaptable when value, dependency, uncertainty or the Product Goal changes.
Do story points equal hours or days?
Not reliably. Story points are a team's relative comparison of effort, complexity and uncertainty within its own context. Turning them into a universal time rate creates false precision and encourages comparison between teams that estimate differently. Use observed team outcomes for forecasting, retain ranges and uncertainty, and never treat a point value as a contractual duration.
What makes a useful Sprint Goal?
A useful goal expresses one valuable objective that unifies selected work and helps the team make trade-offs during the Sprint. It should not be a copied task list or a slogan so broad that any output qualifies. Ask what meaningful product condition should be different by the end of the Sprint, then phrase that outcome clearly.
Assessment move
Use small backlog sets and reorder them after one fact changes. State the Product Goal first, then annotate each item with value, risk, dependency, learning and size. This makes ordering reasoning visible and prevents a single numeric score from hiding judgement. Practise relative estimation with comparisons rather than hour conversion, and include uncertainty in your explanation.
For Sprint Planning, answer why, what and how in that order, then write a Sprint Goal that is more coherent than the selected item list. Create one board for a practice scenario and define what each column means, including where quality checks occur. Finally, test the plan with an urgent request or failed dependency and explain how the Sprint Goal guides adaptation without lowering the Definition of Done.
Working through Product Backlogs and Sprint Planning in FIT2002? Sia is AskSia’s AI Project Management tutor — ask any FIT2002 Product Backlogs and Sprint Planning question and get a clear, step-by-step explanation grounded in how FIT2002 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
