PMGT5871 Chap.12 Product Backlogs, User Stories and Estimation
Product Backlogs, User Stories and Estimation
The product backlog is the requirements source of an Agile project. This chapter explains the product and sprint backlogs, epics and personas, then the user story template with acceptance criteria and the INVEST checks.
It covers relative estimation with T-shirt sizes, the Fibonacci scale and planning poker, and finishes with value-based prioritisation, working a 100-point allocation and a paired comparison for a tutoring app of our own.
The Week 10 tutorial works through the same chain this chapter follows, using the second case study: create personas, write user stories with acceptance criteria, estimate their size as a team, then prioritise them. Done carefully, that chain produces a backlog ready to load into Jira in Week 11, which is why the quality of the stories here directly shapes Group Assignment 2.
What this chapter covers
- 01
Product backlog and sprint backlog
- 02
Epics and their breakdown into stories
- 03
Personas and how they guide priority
- 04
User story template and acceptance criteria
- 05
The INVEST model
- 06
T-shirt sizes, Fibonacci points and planning poker
- 07
Value-based prioritisation, paired comparison and the 100-point method
Worked example · free
Prioritising stories with the 100-point method
- 1Check each member's allocation sums to 100.
- 1Totals: book 135, cancel 65, photos 65, rate 35.
- 1Break the tie at 65 with a paired comparison and rank rate a tutor last.
Key terms
- Epic
- A large user story, usually more than one sprint can complete, grouping stories that share a strategic aim.
- Persona
- A detailed fictional character representing a group of users, used to understand needs and set priorities.
- Acceptance criteria
- The objective conditions that decide whether a user story is done at the sprint review.
- Story point
- A relative measure of a story's size covering work, complexity and time for one team.
- Planning poker
- A consensus estimating technique in which developers reveal cards together and discuss differences before re-estimating.
Product Backlogs, User Stories and Estimation FAQ
What is the user story template?
As a [persona], I want to [goal], so that [benefit], followed by acceptance criteria. The want-to part describes intent rather than interface features, and the so-that part explains the overall benefit the user is trying to achieve.
What does INVEST stand for?
Independent, Negotiable, Valuable, Estimable, Small and Testable. The slides put a ceiling of roughly three weeks of one person’s effort on a small story, and add that a story nobody can test can never be confirmed as done.
Why are story points not comparable between teams?
Points are relative to the team, the sprint and the complexity of the work, so a 5 for one team may not equal a 5 for another. Velocity forecasts therefore use each team's own history.
How should acceptance criteria be written?
As bullet points or in one of two formats: when an event occurs, then this should happen; or given a precondition, when an event happens, then an expected change follows. Either way they must be objective enough to decide at the sprint review whether the story is done.
How does planning poker work?
The product owner reads a story, developers ask questions and each privately chooses a card. The cards are revealed together. If the values agree the estimate is noted; if not, the team discusses the difference and estimates again until it reaches agreement.
What is the difference between the product backlog and the sprint backlog?
The product backlog lists all features, defects, issues and infrastructure needed for the final product and is updated regularly. The sprint backlog is a subset of it covering the deliverables for one time-bound sprint, with each story's details completed before the sprint starts.
Exam move
Write ten user stories for an app you use, each with a so-that clause and acceptance criteria in the given, when, then format, and run every one through the INVEST checks. Size them with Fibonacci points, then split any that you sized at the top of the scale. Practise the 100-point method and a paired comparison on the same set and see whether they agree.
For revision, keep a card with the backlog hierarchy from product backlog to tasks and the rule that work missing from the backlog is not a requirement. As a final step, load your ten practice stories into a simple table with points and priority, which is the shape of the backlog you will build in Jira.
Working through Product Backlogs, User Stories and Estimation in PMGT5871? Sia is AskSia’s AI Project Management tutor — ask any PMGT5871 Product Backlogs, User Stories and Estimation question and get a clear, step-by-step explanation grounded in how PMGT5871 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
