Planning in Agile varies a lot given the kind of project, the size of the team, the dependencies and commitments to stakeholders. Because of this, Agilists around the world hold varied opinions on how much one should plan in an Agile project.
There is no prescriptive answer to that question, however, the level of detail one can go to before putting together a project plan can be decided based on the given circumstances.
Minimal planning is working out of a prioritized backlog of stories
Prioritizing stories based on business value is almost always the first step in plannning. Once we have a prioritized product backlog the team can start working on the highest priority story from the top of the stack.This mode of working is particularly useful when there are no strict timeline commitments for the stories to be released to production. This might happen in scenarios where it is a small application and the product owner is comfortable with doing a release when he feels that enough is built in the application to be seen by the users. This can also happen when the team is working on enhancements or bugs post a production release, and is waiting for business to decide the next milestone. This works well in small teams of 2-3 pairs.
Planning a Single Sprint
The next level of detail is planning atleast for a Sprint(2-4 weeks). A Sprint backlog (or an Iteration Plan) helps in creating visbility for a very limited period of time which is useful both for the Product Owner as well as the team. An example of a Sprint commitment to a product owner can be delivering 20 points of work from the product backlog which translated to 5-6 User Stories.
Planning only for one Sprint is useful when the Product Owner does not have longer term visibility on features/stories for the team. This might also happen when we are waiting things like user feedback etc... to determine the next set of stories to be played.
Doing Release Planning across Sprints
A longer term view of the feature pipeline can help the team build an exhaustive release plan across Sprints. This can be done by slotting stories in an Iteration and even looking at paralellization of stories between development pairs. This sort of activity is best done by sticking stories putting up all the stories on a release wall and collaboratively building the release plan on it.
The number of stories slotted within an iteration is guided by the velocity the team thinks it can achieve. This release plan gives a planned burn down of the scope which the team sets out to achieve and acts as a great metric for the team to measure "How are we doing ? "
Doing Release Planning for multiple work streams in a program of work
Doing a release plan for multiple workstreams in a program is extremely helpful to identify dependencies across streams. It also helps rollup a program level burn up across all teams in the entire program of work. This is particularly useful when running a large program with multiple work streams where tracking progress and dependencies on a day to day basis becomes difficult. Doing a little more of upfront planning helps in the long run.