I've never worked at a place where I've been allowed to say no, I think scrum working the way in which you describe is more the exception than the rule.
A well-functioning team is composed of skilled professionals. If you are being asked to do something, it is because someone else has a problem that needs to be solved. "No" is an especially unhelpful response to that scenario. Other approaches can work:
- "No, but how about this alternative idea?"
- "No, this prerequisite is required. How can we make that happen?"
- "Not without causing these other problems – let's decide if it's worth the tradeoff"
- "No, that idea is fundamentally impossible. Here's why."
If you work in an environment where engineers are never listened to, then it's a bad environment. But similarly, engineering requirements are not the only ones, and it's important to realise that quite often an engineer doesn't have all of the required information to make the correct long-term decision.
Either give the product owner a reason and a way to work towards what they want, or an alternative that (hopefully) is just as good.
Even if that didn't happen you're never going to win, because the b.a.'s have no other job than playing this verbal judo, while you also have to spend your time getting conplex technical things to work. You're like someone who goes to a karate class twice a werk fighting against someone who's life is dedicated to training.
I've never been in an environment where you could say no to the b.a.'s under agile either. And I've tried being more articulate as well and that just results in the same claims to your manager as "no" does that you're not being cooperative, a team player, etc.
I'm pretty sure after working several places that did agile that most of these "worked great for me" stories are made up.
I've never met another dev in real life who did something other than agile and preferred agile.