A milestone can be thought of as a version of the project, a deliverable, a release.
For instance you might define the milestones for a project as:
Proof of concept
In GitHub you can define milestones and then assign issues and pull requests to a specific milestones. Or you can create an Issue for a milestone and just list all the issues related to that milestone in that one Epic issue.
Every project in the Foundation should have at least the next milestone defined.
KPIs are Key Performance Indicators, these are just things you are measuring to track the projects progress.
When deciding the milestone PMs also need to decide what KPIs, what metrics they will use to measure progress towards that milestone.
You can have one KPI or multiple.
In meetings PMs are expected to report a single %age progress towards the next milestone for every project
For example you might define a milestone as “Requirements Gathered” with KPIs:
Number of requirements submitted.
Number of requirements approved.
% requirements approved / target of 10 (assuming say we are targeting 10 core requirements)
Every project wiki page should have a section called Milestones where we list the known/next Milestones, like so:
ID: Name of the Milestone
Deliverable: What is the expected set of deliverables for this milestone.
Success: How will we define a successful milestone?
KPIs: What metrics are we going to use to track our progress towards this milestone?
The method described below is the proper way to setup milestones in GitHub.
However for smaller projects with just a few issues, or for repositories that are used to track multiple projects, it’s ok to manually track milestones using another solution, you can use summary GitHub issues, a view on a Project Board or even a separate Spreadsheet.