One of the initial questions raised about Agile development is "how can we plan for a two year project when the plan can change every month?". This is a fair question.
The answer is that you can't plan the exacting details of a project two years out. You can try, which is the major problem facing many game development projects. Typical long-range planning tends to lock down features and adjust the budget, and schedule to match. Agile's approach is the reverse of this. Features are the most flexible "lever" we have in controlling the budget and schedule. Anyone who has been on a team that has had a lot of people added on at the end in an attempt to keep schedule has seen the folly of this. With Agile, we iterate on the features to insure that the feature value we choose to ship with consists of the best features.
Agile projects use "releases" which are version of the game that are potentially "release-able" every three to six months. Think of a release as a version of the game you would publish on a game magazine's disc. It's debugged, optimized and passes some of the more significant TCR/TRC tests.
Releases are superior to milestones because they are true measures of the game's value. They can be focused tested and shown to larger audiences at E3. Everyone that has developed a demo for E3 knows the value of having the team drive towards the goal of getting a real product on the floor for that show. You discover the reality of what you thought was valuable and what was not building that demo.