It is common enough for those packs of estimation cards to include one with a question mark on it, to denote the "I can't estimate this sight unseen" scenario. The reason it's common is because often people are presented with stuff that isn't well-understood enough, and it's a very good idea not to pull a number out of one's rear in those situations. Don't be afraid to use that card (or do the equivalent and just say so).
If you are afraid because you will be marked as 'not a team player' or whatever, you have management culture problems that neither Scrum nor any other imaginable software development process will fix on its own. They will all end up feeding an idiotic garbage in/garbage out cycle of overpromising, crunch, burnout and general misery, with the superficial appearance of whatever process it was supposed to be.
I think that's a kind of waterfall strawman. In every other discipline, you would ask engineers for an estimate. It's insanity to do otherwise.
I studied engineering in university and profs had plenty of stories about bosses sending business analysts to look at similar projects, generating a time estimate from those projects, and then send that estimate to the engineers as their deadline for completing the project.
It being insane doesn't stop people.
So if you take an estimate and turn it into a deadline, in the perfect case, the deadlines can only be made 50% of the time.
Of course, in practice there is bias, there are things you forgot to include in the estimate.
Why don't you work that in to your process. It's called Agile for a reason.
Snark aside, that's the difficulty. The fix for everything in Agile is - instead of adopting some sensible practice (that could actually have been discussed in academic literature), have an argument about this with your team members, maybe they will get it.
It's a return to medieval times, where all the expertise was just the experience of the master.
Agile books are hilarious because they are trying to not be prescriptive about process, while being prescriptive about process. Within that dichotomy, is the assertion that you can create your own process. So, in fact, it is usually in those books that you can make your lists for your team.
In the end, Agile/Scrum are a bunch of hand-waving rituals, which is close to what ends up happening within every software development team everywhere anyway.
You could start with something suggested in a book. But you need to be ready to adjust your process when you identify when something is not working.
Still estimates are considered extremely important...
This has benefits and downsides. One of the one hand, the development team getting to control the estimate helps to control the workload.
On the other, I agree. Why are we pulling estimates of effort out of thin air? Why are we being asked how long it will take to do work in sections of code we have never seen?
Planning could be far more accurate if we just got a proposed task list a day before planning.