At least, that way, you'll be prepared for the less urgent features when you get to them.

This doesn't, however, help reduce waste in the same way that pushing back and questioning the need of each story. Oftentimes the stakeholder will think "this thing is super important", without realizing its functionality is unnecessary, or is already in place if you just do some simpler or better thing, or will be useless without some other story done first (that isn't ranked higher). You need to help point these things out.

A real life example I can give is on a project I had in the past, where we were replacing an existing software solution. The customer was adamant that they needed to be able to specify what piece of hardware a job was run on. They were used to the way the existing system worked, where that was the only way you could keep track of where the job was, to see its status, cancel it, etc ("I put it on machine #44, so let me scroll down to machine #44 and see the job"). We wanted instead to just automatically assign the jobs for them, and provide them a search and filter (which they already wanted and had ranked highly), to be able to select, say, just the jobs they had created, that sort of thing. No matter how we tried to explain it, they didn't see that the latter would completely supplant the former, so why do the former. We ended up doing both; they ended up never specifying the piece of hardware. Other places on that project they -did- listen to us, but that one sticks out in my head the most because they didn't.

This is a noble idea except that there is more than a dozen ways which "urgency" can be measured. Do you measure by its deadline, where the requirement is sourced, its dependencies etc.