I find that when you have many dependencies like this it 'breaks agile'. Basically you are forced to write a spec for the dependent system changes, even if it's just 'in your brain', based on your expected requirements for the end product. These then turn out to be wrong, or delayed, or dependant on another team, or whatever and muck up your sprint.
One way to get around this is to make your dependant services more generic. So instead of service.getCustomers, service.GetOrders for example you expand it to be service.queryAnythingDymanically.
Instead of DataAccessLayer.RunStoredProc you change to DataAccessLayer.ExecuteEntityQuery etc
This then reduces the situations where an upgrade to the dependant service is required by a 'front end' change.
There are downsides though. The more generic a service is the harder it is to test, performance may drop and security is harder to verify.