Wtf does it even make sense to ask devs to do estimates for the spike, planning and the implementation of a big feature containing other features which nobody has any idea how long it will take to do and what are the dependencies and to try to fit it in the next quarter release?

Agile my ass.

It makes sense, but they also need to do their homework.

They can't simply say: I want that the system can track boxes in trucks and warehouses.

They need to specify what they want to happen if a box is stolen from a truck, for example.

When we get question on time we have the option to specify either unknown if we judge there are to much undefined, or to large if we determine that the scope is to big for a guess and the uncertainty would be to much.

In both cases it will need to be broken down into smaller tasks before a time estimate will be done.

Happens to us all the time. The worst thing is, let's say the devs said

"so these will take 2 weeks. We know nothing about library XYZ so it could take from 1 week to a month... we're not sure."

What management hears:

"2 weeks + 1 weeks tops, maybe less if we're not being lazy"

@Voxera yeah trying to break down, doing more research and design the work in modules is what I usually do and also what I started doing initially, but I have been told to bundle everything vaguely in huge tasks.

I know from experience doing huge estimates with no information never works and I have warned the estimates will be insanely innacurate or quite possibly underestimated, but management does not seem to care. It also seems I'm forced to fit my estimates to what management wish to have.

It's just frustrating to be forced to do botched work when you have time to do it properly.

@PepeTheFrog to bad to hear, that means either they are morons or do not care if it fails.