A common approach is to do a rough initial estimate of the Product Backlog using a sorting method like the bucket system, with variations described by ThoughtWorks or Mountain Goat Software. A few other techniques are also listed for reference at the very bottom of this answer.
The general idea of the bucket system is that you identify a baseline story, assign it 1-2 story points, and then guesstimate relative sizes of the rest in relation to the baseline. It's similar to Planning Poker in some ways, but intended to provide quicker results at the expense of granularity and accuracy because you aren't doing the level of decomposition that you would normally do during Sprint Planning or Backlog Refinement.
This type of sorting can be very quick when compared to Planning Poker, especially if you remember that the point of the initial estimate is to do high-level release planning, rather than plan out all your sprints in advance. In other words, you are really just doing a rough estimate of the first couple of sprints, while the rest of the Product Backlog is full of themes and epics that you may or may not ever get to under the YAGNI principle.
You can use bucket-sorting, or other similar techniques, to create inputs for the remainder of the project. You will still need to replan and re-estimate each Sprint, and determine how (or even if) you want to form a release plan for the overall project. I discuss each of these topics in more detail below.
Replan and Re-Estimate Every Sprint
Remember that initial backlog estimation is the start of a series of processes, not the end-state. You will re-estimate the likely stories for each upcoming Sprint again during Backlog Refinement, and do another fine-grained estimate during Sprint Planning at the start of each Sprint.
In other words, your initial estimates will change over time:
- As the Cone of Uncertainty narrows as the team and stakeholders gain additional domain knowledge and feedback from previous iterations.
- As changes are made to the Product Backlog or user stories, since the Product Backlog is a living document that is expected to change throughout the project lifecycle.
- As the team gets better at estimating, and as the team's capacity over time stabilizes.
- As just-in-time planning for each Sprint is always going to provide a more accurate forecast than guesstimates from project initiation.
Your release plan contains high-level estimates of the "broad brush-stroke" variety, while your Sprint Backlog really ought to contain a more granular forecast of the work immediately ahead of the team in the current Sprint. Some teams use bucket-sorting for Sprint Planning too, but I'm a big fan of Planning Poker to estimate in Story Points during the first half of Sprint Planning, and sanity-checking the Sprint Backlog tasks against the team's estimated capacity in ideal hours or calendar days during the second half to avoid overcommitting.
Your mileage may vary by technique, but the rule of increasing granularity as you move from Release Planning to Sprint Planning should still apply.
Plan Just Enough for Agile Release Planning
The main goal of initial planning is generally to make an educated guess about velocity, and to provide an initial baseline for agile release planning. It can be tempting to estimate the entire Product Backlog, but in my own practice I've found that estimating just enough of the backlog to forecast the first few sprints is enough to make educated guesses for the overall project release schedule. Most of the remainder of the backlog won't survive the continuous cycle of Backlog Refinement, Sprint Planning, and modifications from Sprint Reviews and Sprint Retrospectives anyway.
A decent Jedi mind-trick here is to do the bucket sorting, guesstimate the initial velocity, and then see if the stories that would be picked for the first Sprint feel like they would fit. Sometimes, you'll find that something just feels wrong about the estimates of Product Backlog Items or team capacity, while other times you'll feel like you have at least an 80% chance of meeting your first Sprint Goal using the velocity and story-point estimates you're guesstimating as your baseline.
In agile release planning, the traditional triple-constraint still applies, but the dimension that most often shifts is scope. So, you can still form a release plan based around key milestones in the project using epics/themes, but you will have to adjust your Sprint Goals and refine the scope of each Sprint to fit the release plan. This approach doesn't require a full estimation of the entire backlog.
Alternatively, you can base your release schedule on how long you expect it to take to complete all work in the initial Product Backlog. If you do this, you will need to periodically re-estimate the entire remaining backlog, and track a release burn-down in addition to ensuring you have a potentially-shippable product at the end of each Sprint.
Obviously, I strongly recommend the former approach. Still, if project scope is fixed but schedule is an adjustable dimension for your project, then the latter approach can work, too. It's just more work, and in many cases less accurate during early-stage planning.
These links aren't particularly canonical, but they address some well-known alternatives to either planning poker or the bucket system. There are certainly others, but these are among the most common:
Relative Mass Valuation has a lot of mindshare in the agile community, but despite the name I think that TFB/NFC/1 is a surprisingly useful technique that deserves more attention. YMMV.