This is what you do in many agile methodologies. Have the stakeholder rank their stories, understanding that it's a queue you will pull from. They're free to ra

This is what you do in many agile methodologies. Have the stakeholder rank their stories, understanding that it's a queue you will pull from. They're free to rank them however they want (so 'urgency' doesn't need to be defined; it's entirely on them to subjectively figure things out). As a dev, you just pull from the top. 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.