The purpose of estimation is not precision. It's communication — and triggering the right conversation.
Relative sizing works by comparing items to each other rather than estimating in absolute hours. "This story is about twice as complex as that one" is a meaningful and reliable statement. "It will take exactly 6 hours" is almost always a guess presented as a fact.
Story points, t-shirt sizes, Fibonacci numbers — these are all just vehicles for relative comparison. The specific scale matters less than the consistency of the team using it.
Planning Poker is the most common relative sizing technique. Each person estimates independently and reveals simultaneously. Disagreements trigger a conversation — which is the actual value of the exercise. When a developer estimates a story at 2 points and another estimates it at 13, that gap almost always reveals a misunderstanding of the requirement or an unspoken technical concern. The number forces that conversation to happen.
Two things to be clear on:
Points measure complexity, not time. A 5-point story takes different hours for different developers. That's expected. Points are about complexity and uncertainty, not duration.
Estimates belong to the Developers. The PO provides context and answers questions. Developers estimate. This is not optional.
Exam tip: The Scrum Guide is explicit: Developers own the estimates. Any scenario where the PO, management, or a stakeholder sets estimates is describing an anti-pattern. This is a common PSPO exam trap.