A good estimation at its best is an informed Guess.
Traditional method has been to use historical data and provide an estimate of the effort required to complete an activity or task. The High level activity, could be broken down into sub activities and estimated at appropriate granularity & subsequently aggregated. The team may or may not participate in arriving at the estimates, they are at times arrived at by an expert group.
Once committed and execution begins, the project may start deviating from the plans. In such cases, the Program manager is dependent on the value of Remaining Work (which is continuously changing, and varies as time progresses) to provide re-planned dates.
Historical Data is from the past project, only after completing this running project, will the information gets appended to history data and re-adjusted. (historic values does not provide much support to the current running project)
Looking at the relative Size estimation that is prevalent with Agile processes, a different paradigm is followed. Metaphorically speaking, Here too the High level Activities (Epics) are broken down to smaller activities (Stories). But here the stories are compared against each other to arrive at their relative size (XS, S,M.L, XL etc.) and Points are assigned to them. The team participates in the activity and estimates are arrived at based on discussions and concensus
A few sprints are executed and schedule commitments are made based on the teams current velocity (not dependent on historical data); hence the schedule reflects the teams current performance.
Here too there can be deviations from plan. there is a better view of the Remaining work in terms of pending Story points. In case we realize the estimates are wrong, they tend to be wrong uniformly, hence the re-plan can be based on proportional readjustment across all stories (for example 1.2 x).
Thus Relative Size based estimates are better option with higher confidence on the resulting plans.