A common criticism of using “relative size” is that developers tend to estimate in ideal days and then translate it to relative size.
I disagree. I find myself doing the opposite. This week, when asked for an estimate i said “twice what it took us to deliver X”. Where X was a feature that we estimated would take one week and actually took two.
Some people may also dislike relative size because it takes a few weeks to get a meaningful “velocity”. This is actually a good thing – it highlights the trap of projecting from wishful thinking rather than empirical data.
So why “relative size”?
It avoids a common pitfall of absolute size: simply being overly optimistic in all your estimates. Relative size fits better with the Agile principle of feedback: “The primary measure of progress is working software”.
Relative size also makes it hard to game the system.
No matter which approach you take, estimates should factor in risks, unknowns, etc. All things be equal, a high-risk feature should have a higher estimate than a low-risk feature.
It may even be worthwhile doing a best-case and worst-case estimate. I suspect there are generally more potential delays than potential windfalls.