There's not just one feature
where a single feature can span across several Micro-services?
For all intents and purposes, this isn't one feature spanning across several microservices, this is a collection of features (one per microservice, or more) which together achieve a desirable behavior.
When working with microservices, abandon every intention you have of treating work as if it spans across several microservices. Doing so inherently infringes on the independent nature of microservices.
The short answer here is that when you consider features in scope of a specific microservice, not a collection of microservices; then you effectively have the same situation as you have for a monolith, which you indicated you're already familiar with.
After all, a microservice is really just a miniature monolith (in a field of other miniature monoliths).
While you can definitely write an integration test that spans across multiple microservices in order to check if they interact correctly with one another, TDD guidelines generally focus on a per-codebase scope, not that of an entire ecosystem of codebases and how to manage expectations with different owners, tech stacks or development schedules.
Feel free to write that service-spanning test, but accept that it's probably not going to tell you much until you really know how that test should consume all of its constituent components.
How to structure the work for these separate features?
This is where the next part of the advice can diverge: do you want the theoretically elegant approach, or the more complex but realistic example?
Theoretically, if microservice B depends on something in microservice A that doesn't exist yet, then you should develop A's feature and release it before starting work on B's feature.
This is the simplest way to structure the work. First build the core, and then build the things that depend on it. It's simple. It will probably take the least amount of overall manhours to develop. But you lose out on the ability to do things concurrently, which might cost a bit more manhours but does mean that you can deliver the whole package at an earlier calendar date. Whether you value total hours works, or calendar date of delivery, depends on your company.
If you want to develop these concurrently, A and B's developers have to sit down with one another and agree on the interface (i.e. A's API), expressing the endpoints and models used in those endpoints.
Once you've established the service interface; A's development can start (like it would have even in the first scenario), and B's development is able to already start, as it can be built against a mocked version of A's API.
If you accurately agreed on a working interface, then at the end of the process you should be able to swap out the mocked API for A's real API. Obviously, there's a decent chance that some things have changed since then, but that's the nature of trying to build against A's API before the real thing exists. This is why I said that it probably is going to take more overall manhours, as you both have to spend time building a mocked version of A's API and you increase the odds of needing to revisit A's interface based on things you realize during the development process.
