The release planning meeting is a highly recommended planning session in which features and themes are reviewed and prioritized, key dates and milestones are established, and the team determines, based on their velocity (prior or estimated), roughly which features will be delivered in the timeframe identified.  The ultimate goal of the meeting is to produce a high-level release plan with delivery dates, number of iterations and the primary stories that will be delivered.  

The key to planning a release is knowing the team’s velocity (how much estimated work they can complete in a single iteration).  If velocity is known and the scope is fixed, the team can calculate the number of iterations required by dividing the total estimate of all the features by their velocity.  If the delivery date is fixed (as is typical), then velocity is multiplied by the number of iterations to get an initial sense of how many features can be delivered. If the development team's velocity is not known, then they must provide an estimate for it, and the release plan should be considered less precise for the first few iterations until a reliable velocity for the team can be derived.

The initial release plan is understood to be fairly rough, yet it must be detailed enough to get the team started.  In agile projects, planning occurs continuously and course is corrected as the project progresses and more insight becomes available.  One of the primary mechanisms for course correction is allowing the release plan to evolve in response to all kinds of user, stakeholder, technology, and market feedback. It will take at least a couple of iterations for team velocity to settle down. Iterations will sometimes deliver less functionality than was planned for, and sometimes more. Features, architectural choices, design choices, or framework or technology choices might prove to be too risky or simply unworkable. The user interface might require revision. Staff might be lost or added. Feature priorities almost always change. All of these factors will help teams revise and refine the release plan. When each new iteration plan is published,  a revised release plan that reflects the new reality should also be made available.