I break down the feature/story into several tasks and label them as A) backend or B) frontend (occasionally there is only 1 or the other but usually there will be at least 1 task for backend and 1 for frontend).
Link those tasks back to the master feature /story item. It will be marked done only when all the associated tasks are finished.
Then do those tasks separately, usually the backend first, and then pass it/assign the frontend task.
The backend task is only considered finished when there are passing tests written with the frontend consumer (developer) in mind, proving they are provided with everything they will need.
Document the API in a way/place a frontend developer can knows and understands.
If you write the requirements for the tasks very clearly, the whole process could go smoothly without a lot of back and forth between the backend and frontend developer.
But sometimes there are things that weren't foreseen and so there could be a bit more to go back and do on the backend.
More often than not there are folks that are better at/hired for backend or frontend, so only assign the appropriate tasks to each of them.
Sometimes there are full stack developers/solo developers who can do both. In that case I still follow this approach.
I break down the feature/story into several tasks and label them as A) backend or B) frontend (occasionally there is only 1 or the other but usually there will be at least 1 task for backend and 1 for frontend). Link those tasks back to the master feature /story item. It will be marked done only when all the associated tasks are finished.
Then do those tasks separately, usually the backend first, and then pass it/assign the frontend task. The backend task is only considered finished when there are passing tests written with the frontend consumer (developer) in mind, proving they are provided with everything they will need. Document the API in a way/place a frontend developer can knows and understands.
If you write the requirements for the tasks very clearly, the whole process could go smoothly without a lot of back and forth between the backend and frontend developer. But sometimes there are things that weren't foreseen and so there could be a bit more to go back and do on the backend.
More often than not there are folks that are better at/hired for backend or frontend, so only assign the appropriate tasks to each of them. Sometimes there are full stack developers/solo developers who can do both. In that case I still follow this approach.