git (regardless of process on top of it) is not well suited for handling multiple deliverables unless in fact those deliverables are real deliverables. So for example if your company has a logging library that has its own sprints, its own requirements, schedule and delivered versions then that is a deliverable library. And the applications in the rest of the company would use a delivered version of that library. With git that would then exist in its own repository. In comparison what often happens is that there are several large entities which compose a single delivered application/system. A change in one part of the system invariably requires a change in another one or even several entities. All entities are manage in one sprint and a release involves all of the entities at the same time. I am guessing you have the second. And it is unlikely you will ever have the first. Possible just not likely. The only way to really ease the burden with the second is to very carefully manage dependencies. And that is not something that technology does - it requires a person. Thus if you add a new feature then the back end code is finished and, hopefully if possible, QAd, before the front end is even started. Obviously this is a probably when modifying existing code but then you can add new functionality as different endpoints and denigrate the old endpoints for removal in a future sprint. Again this is a manual process. darkliahos wrote: I would love a few opinions and experiences on people who have battled with this issue. A good a conscientious project manager can help a lot. There are not a lot of those however.