A fixed schedule is not responsive to changed priorities
A schedule that is written out in detail in advance will need considerable re-work if some of the work needs bringing forward in priority and implemented before other work that currently is scheduled earlier.
In general it is not a good idea to do detailed planning too far in advance. Where there is a high degree of dependency and a distinct critical path, it is justified in planning further in advance than when the individual tasks are in short dependency paths. It should also be noted that tasks on the critical path can possibly be slimmed down until only work that is itself on the critical path remains in those tasks. We want some balance between long term planning to give us ball-park figures for completion dates and short term detail to ensure the immediate work is resourced efficiently and is progressing as expected.
IterativeDevelopment gives us the opportunity to plan in detail for only one iteration in advance. Subsequent iterations can be sketched out, with the detail filled in toward the end of the preceding iteration. This is one specific variant of the WorkQueue, which is a generic solution that finds many variant forms. This pattern gives us an idea of how much work there remains to do, without saying when any particular item will be done.
The PlanningGame of XP gives detailed plans for the immediate iteration, and a pile of remaining work that is under consideration and estimated, but not yet scheduled. SCRUM has a variant called BackLog. These patterns do more than merely facilitate reorganization of work priority.