I depends on who you talk to. IMHO, the most important thing is that every single story has to have "business value". In other words, it has to have something where if you put it up on a board and said, "My team did this today", anybody in the management structure would say, "That's wonderful news". I also feel that you should try to have stories that average between a day and two days in length -- so it's pretty darn tough to think of ways to meet both criteria. These days, I'm unable to due pure XP, but I often find that if I manage to build a backlog like that, then it barely matters what else I do: it's going to be successful.
The main thing is that every single change needs to be vertical in nature. You are never making stories where you say, "I'm going to add this functionality to a library. Later we'll add the UI and finally, we'll add the data to the DB schema and then ship". But it means that you need to design your software quite differently in my experience.
Even just from the DB level, you need to have things set up so that you can make very quick changes safely. You need to be able to change the schema, do migrations and make sure that rollouts can be done safely -- and it needs to be done on the order of an hour or so. That probably seems impossible to some people, but it's one of the reasons you can't really take a legacy project/team and say, "From today we are doing XP!"
Similarly, you need to be able to make changes to your infrastructure quickly. So if you have some big set of microservices and each small change requires a signoff from some group somewhere: well, it's not really going to end well. You need to be able to make that change and get everything working end to end in hours, not days/weeks.
One of the things that a lot of people have difficulty with XP is that it's generally incompatible with nailing communication specs to a wall. One day, I may need to add something to the API. The next day I need to be able to change that API. If someone comes to me and says, "You need to know everything you want this API to do for the next 3 months so that we can have a sane versioning system", I'm totally screwed. I don't know what I'm going to need next week let along 3 months (or whatever) from now.
For a lot of people, this stuff is just way too different to deal with. XP comes with the subtitle, "Embrace change". It literally doesn't work unless you decide to go whole hog on it. I've been successful introducing it to some teams, but on others I don't even try.
To try to answer your question a bit more closely... it's probably not what you imagine. It's not like you have people telling you how everything is going to work all the time. However, you are constantly thinking about it. Sometimes you'll have developers say, "I want to work on X" and you'll respond, "Why? How are we going to give value with that work?" And then they think about it and say, "Well, what if we altered the work flow here. That would allow us to remove this stuff. And then if we added this, it would mean that we don't need that library any more", etc, etc, etc. And instead of telling management that today "We removed some technical stuff" or "We got rid of some old libraries", we say, "We improved the workflow for the customer which enabled us to simplify the code at the same time".