Edit Those Epics
Managers are accustomed to working in timeboxes. To them, the iteration is a timebox. But, they also are accustomed to features spanning multiple timeboxes, and that’s not OK in agile.
The managers’ fixed mindset is bumping up against the technical team’s change mindset.
But, in order to have releasable product at the end of an iteration and to keep iterations short enough to get feedback often enough, you need small stories. That means you’ll start with epics and decompose them into stories.
What’s the first valuable thing—the smallest chunk that delivers business value to the customer, to the developers, to the testers, to someone—that we can do that we can show to someone at the end of a short iteration? Is that small thing a story? Is it small enough to be completed inside an iteration, maybe by the entire team? If so, complete that story in the iteration. If that thing is not a story, what would make it a story? If it is not small enough, can you decompose it further?
Make your stories small enough so that you, the team, can finish more than one story inside an iteration. My rule of thumb is that you should be able to complete a story every day or, at worst, every two days. If you can complete stories more often, that’s even better