Release Planning at scale

I've done different techniques in various companies. With my current employer, we are using epics to organise a set of user stories into a coherent customer-facing deliverable.
The epics have a target release defined, and there is either a technical lead or a project manager responsible for talking to the various Product Owners in the front-/back-end teams and making sure their priority and sprint planning takes the overall goal and release planning into account.
With JIRA (our tool of choice), you can use various epic reports to track the same.

We discarded the idea of single backlog across teams (or parallel backlogs) since management of said backlogs became too challenging.

I can go into more details of course - depends on how far you'd like to go.

Separate front-end and back-end teams will usually need to co-ordinate their release plans in order to deliver features of business value. You could therefore reduce the amount of release planning needed by re-organizing into feature teams instead. This will make it easier to orient a release plan around business needs rather than technical ones.

Feature teams often bring more challenges than they solve. They don't work well when you have many small projects going at once, and they don't promote in-depth knowledge of specific components or engineering-driven improvements.

In some organisations they do work, but it's not the ultimate answer to the release planning question.

The first consideration in release planning is to eliminate Development Team constraints. The focus must be placed squarely on the value that is yielded by each release to the Product Owner. Feature Teams are not essential to Core Scrum but they are a good practice, and hence their merits are given particular consideration when implementing Scrum at scale.

Development Teams that are not organized in terms of feature release are more likely to increase release planning overhead, including the communication that is needed to effect a release and having to resolve multiple integration points before the value of any one feature can be evidenced. It is therefore important to consider this matter first when optimizing release planning arrangements.

Theoretically this is all correct. Practically, feature teams come at a cost for the reasons named in my previous reply.

To add to that, developers do not work solely on one product or feature. They also support junior team members, deal with customer escalations, do maintenance on a component, have older projects that are being deployed etc. All of these require daily interaction between component owners, and feature teams go against that.

They are definitely worth considering though. From personal experience, tried feature teams on several occasions - each time performance was worse than with modular teams.

Feature teams may go against organizational assumptions about value and how it is best delivered. These assumptions are often reflected in an organization's configuration, such as by layer or by geography or by component.

Enterprise agility requires deep and pervasive change, and the sponsorship to achieve it while an organization is in flight. A dip in productivity is to be expected when implementing feature teams, although it is a short-term one. This is recognized in the Scaling Professional Scrum framework. However, I'd personally agree that it would not be wise to set about implementing feature teams unless the appropriate sponsorship to do so is in place.