Relative Sizing: Estimate Effort, Not Hours

The mental model

Relative sizing is a way to estimate work by comparing its complexity to other work, rather than predicting the exact hours it will take. The goal is to understand the effort, complexity, and uncertainty of a task relative to a known baseline. Think of it as saying, 'Feature A is about twice as complex as Feature B,' not 'Feature A will take 40 hours.'

How it works

A team starts by selecting a small, well-understood piece of work as a baseline and assigns it a value from a scale. Common scales include T-shirt sizes (XS, S, M, L, XL) or a modified Fibonacci sequence (1, 2, 3, 5, 8, 13...). For every other work item, the team discusses its complexity relative to the baseline and other already-estimated items. For example, if the baseline is a '2', a task that feels significantly more complex might be a '5' or '8'. This process is often facilitated through a technique called Planning Poker to build consensus quickly.

When to use it

Relative sizing is ideal for estimating a product backlog in an Agile framework like Scrum. It allows teams to quickly generate estimates for a large number of items and use the sum of points (velocity) from previous sprints to forecast how much work they can complete in future sprints. It focuses conversation on the 'what' and 'how' of the work, rather than getting bogged down in defending a specific time estimate.

When not to use it

For very short-term, highly predictable tasks, estimating in hours might be more straightforward. If a team's composition changes frequently, the historical data used to calculate velocity becomes unreliable, reducing the forecasting power of relative sizing. The biggest anti-pattern is when management or the team attempts to create a direct conversion between story points and hours (e.g., '1 point equals 4 hours'). This destroys the psychological safety and abstraction that makes relative sizing effective, turning points into just another word for hours.

One canonical example

A team needs to estimate three user stories for a new login system. They pick 'User can log in with email and password' as their baseline and agree it's a '3' on the Fibonacci scale. Next, they consider 'User can log in with a Google account.' This involves an external API, so they estimate it as a '5'. Finally, they look at 'User can enable two-factor authentication (2FA).' This is far more complex, involving multiple user flows and security considerations, so they estimate it as a '13'. The team now has a relative understanding of the effort for each feature without committing to specific deadlines for any single one.