As I described in a previous post, a milestone project schedule is often requested by senior management as a way of a "helicopter view" of the project schedule, focussing the attention just in a few dates that can be tracked and reviewed easily and quickly.
Milestone is defined as a zero length event that is relevant for the project, that can be "project initiated", "product A delivered", "risk matrix distributed to stakeholders" amongst others.
A milestone can be related to the beginning (entry) or to the end (exit) of a project phase, task or activity and which one to report is part of the project management methodoly used and can change from project to project or it might well be driven by the resourcing strategy.
The end of phase, activity or task is relevant when a major deliverable is linked to it, for instance, the end of the analysis and design phase should become a milestone if a key design document will be delivered at that time. It also can be the case that one of the phases of the project is outsourced and they can invoice as soon as the products are accepted by the project manager. In such case, it makes sense to report the "analysis and design phase completed" as a milestone.
On the other hand, when, as part of the project, a number of hand overs need to happen, it is important to highlight the handing over date to allow the taking over team to plan accordingly. For instance, when a software is released and the test activity starts, that is a zero length event that will happen in a particular date and has to be tracked and published to the stakeholders as part of the project plan.