I think the theory is to do a simple end-to-end implementation for $xy and then redo the UI when you add $ab. Or the other way around, if the customer wants $ab first. So the dependency isn't a static thing, it depends on prioritization of the user-facing features.
Implicit in this is the assumption that you're not scared of redoing the internals or redesigning the UI as you add features.
Well, they're closely related. If you have a designer on the team, don't have translations (yet) and it's easy to back out a change, mistakes aren't that big a deal, and everything is easier, faster, and more fun.
But as churn gets more expensive (and this is sometimes inevitable), you want to try harder to avoid it. A process is only agile while revisions are cheap.
It seems like a lot of arguments could be avoided if it were more widely understood that this is a trade-off, with agility on one end and stability on the other, and stability is often good. Particularly when a lot of people depend on you.
It's a common pattern. When a software system becomes complicated and fragile, it's quite common for the developers to get scared of breakage and move slowly.
Sometimes there are fundamental reasons for moving cautiously, and sometimes they're accidental reasons that could be fixed with a better process (such as better tests). Either way, just being more reckless isn't going to help.
Dumb question: If you implement $xy but know $ab and $cd are likely to follow, would it be against scrum to directly implement a generic upload button?
I haven't done scrum but I don't think it says anything about this. Back when I was doing XP (a long time ago), the idea was that it should be shippable in case plans change and you never get to $ab and $cd for some reason.
So if you had in mind a generic upload UI where it would look weird with only one choice in the menu, then better to skip the menu entirely for now. It makes the UI worse, and implementing the menu is more work. Plus you don't want to end up with dead code lying around if plans change, since that could confuse someone later.
But if none of those considerations apply and the generic version is actually easier to implement and the UI is just as good, sure it's fine.
Implicit in this is the assumption that you're not scared of redoing the internals or redesigning the UI as you add features.