Let's suppose the business comes and asks you when will your team be able to deliver a big feature or release. In Scrum, how do you make long-term (half a year or a year) planning?
If the feature (or the release) is big, then the team can't accurately estimate it. You may try to break it down into small features that can be done during one Sprint, but this is a big upfront design, which we try to avoid in Agile, because things can change as we go and this upfront planning becomes a waste.
Scrum and its associated techniques don't eliminate the need for long-term planning but they can help make your planning and estimation tasks easier. If you deliver in fixed-length increments then your estimation only needs to be good enough to estimate the number of sprints a big ticket item will take rather than the number of days effort or duration. Relative estimation generally makes it easier to estimate the epics and stories whatever size they are.
When it comes to actual delivery, the iterative incremental approach means that risk is managed, priority items get delivered first and therefore there's a much stronger likelihood of meeting planned delivery dates. Adaptive agile approaches are sometimes understood as being the complete opposite of more predictive, planned approaches but in many ways the agile approach can help make the outcome more certain and predictable.
It seems like this question is based on the misconception that decomposing a large feature into smaller units of work is a form of big design up-front. It's not. Big design up-front is designing the whole system, or at least large parts of a system, before starting any implementation and integration happens. Although decomposition is a design activity, it's not all of the design, and the smaller pieces enable small portions of the system to be designed, developed, and integrated. In other words, you're deferring the detailed design and implementation of parts of the system until it's needed, a key principle of Lean Software Development. This deferral could also lead to the decision not to do some of the work, a principle of Agile Software Development.
That said, there are two primary techniques that could fit into Scrum.
The first technique would be to integrate as much work as possible into each deliverable. In cases where it doesn't make sense to fully enable the work, there are techniques to hide the work. For example, in software systems, you can use techniques such as feature toggles (or feature flags), keystone interfaces, and dark launching to integrate the work into a single development stream, but enable or disable the work in different environments. As pieces that are fully functional make sense, those pieces can be enabled for end users.
A second option would be to keep the work in a parallel development stream. The work can be deployed to a test environment where stakeholders can provide feedback, but it won't be integrated until it's sufficiently complete. There may be several points at which enough work has been done to integrate, instead of just one at the completion of the feature.
The first option is probably more consistent with the Scrum mindset, but it isn't supported by all types of features or in all contexts. The end goal is to get rapid feedback on the work, regardless of that work being deployed for end-users to use or just in an environment to get stakeholder feedback. Once you reach this, you don't need to plan out so far.
