I would suggest reading the Crispin/Gregory books: Agile Testing/More AGile Testing. A team that has moved to Agile, needs to get out of the thinking of QA/Testing as a separate silo that tests N + 1 sprints after dev is done. Instead, find ways to include them into the teams, embed and let them add questions. Allow your testers and devs to sit and pair for a couple of hours of day, asking questions about what they would test, what they might build, will do a heck of a lot more good in the long run.
Second, you need to start thinking about Continuous Delivery. Maybe not all the way to Production, if you are not there yet, but being able to quickly checkout, build, spin up environments, deploy, and then test subsets of the source code, goes a long way in speeding up testing and delivery. (Btw, you may want to talk about how much time you are spending on automated testing between devs and testers, to help add some checks around this process.) You would be surprised how many of the build issues testers run into are caused because the package/build/deploy process is carried out irregularly, meaning that not only are fixes being waited on to test, but that when they are, you have a long lead time from inception to deployment. Even if the team goes to work on those bugs, the schema in their mind for the work that it was supposed to due may not be there, which means more time to deliver.
Now, on the unit testing side. I suggest you get a chair/book/video and teach your testers to write some of those unit tests. (make them really good at it, make your own build lines if you have to, to get it done.) Then when they you start reporting bugs FASTER than the dev team can deploy to you, they will ask why, and you can say, oh, because we decided the best thing we could do for code quality, was write our own unit tests, and we caught it right away. Eventually the bells will goo off, and the developers will realize they need to be doing some level of unit testing. Results matter.