Agile Clarity: Milestones vs. Check Points

Milestone = an intermediate goal; Checkpoint = a point at which certain criteria are assessed or re-assessed.

Organizations need milestones to measure progress and continuously get inspired to achieve more. Businesses also need check points for assessment of certain criteria.

Milestone is typically associated with reaching a certain goal, before proceeding forward or stopping altogether. Checkpoint signifies points at which the team stops and checks progress against expectations, and possibly adjust.

Milestone (big granularity) means progress checking at iterative way; it is important in overall project progress and if associated goal is not fulfilled, some important analysis and decisions are needed; it is associated with phases and iterations or other important points and it could be related to formal progress tracking. As “no team is an island unto itself”, that “software development” is not a hermetically sealed universe, and that the software development efforts of one team are usually part of a bigger coordinated undertaking / organization.

Checkpoint is a generic progress checking that could have a big granularity (and then is a milestone) or could have a small granularity and it is an “ordinary” checkpoints; the “ordinary” checkpoints with small granularity are useful for intra-iteration checks: be iterative inside an iteration; an “ordinary” checkpoints could be related to formal or informal progress tracking. And a sum of “ordinary” checkpoints could form a milestone.

Milestone = an intermediate goal. Milestones are usually shared or generally visible join points between a development team and the funding organization / program / project etc., and are usually an important shared concern across customer stakeholders as well as the supply organization. Therefore, you can’t unilaterally “disappear” them as agile teams milestones are often shared outside the group - used in presentations, etc. Other projects or business functions (ops, marketing, etc) might come to rely on the milestone date as a dependency.

Checkpoint = a point at which certain criteria are assessed or re-assessed, so that a decision can be made about an initiative/project. Checkpoints are used internally to assess the work to date, but may use their outcomes to help with traditional status reporting. A checkpoint, is what you have in agile at the end of each iteration or intra-iteration. You check to see if you're on course what adjustments are required, and where to go next. The term is in tune with the risk-driven, adaptive nature of agile projects.

Milestone = planned features on your roadmap, it is calculated then promised to your customer in the future from an analysis of your teams' velocity and feature's relative complexity estimates. 

Checkpoint = product and burn-down review at end of each sprint to give you indicators of whether you are on track to meet these goals.

A real milestone is literally "cast in stone”, but Agile milestone is adjustable. Associate the word "milestone" with a journey where the route is known in advance. Reaching a planned milestone means that you knew in advance that you were going to be in exactly that place at some point on the journey. On agile projects, the timing of individual timeboxes/sprints/stages may well be known in advance of the project, but their content is probably not. Therefore the term, while not entirely inappropriate, seems to conflict with the spirit of agile. For example, in Agile, people define the "done" product by letting whoever needs a project to experience working functionality; working functionality is your checkpoint and milestone. In one of the Agile flavors, in SCRUM, releases will indicate milestones, and iterations - checkpoints... SCRUM pre-defines the iteration time line, but not the scope. Scope can change, therefore, your milestones are flexible enough to adapt to changing business needs. If you define milestone as accomplished necessary functionality, that is very useful to business at the point in time - then you have them; if you define milestone as something defined half -a -year ago, and then, it is not so useful to business.

Checkpoint/milestone review for governance: In disciplined agile approaches, the project team recognizes that there's more needed than just delivering potentially shippable software at each iteration. There are other project risks that aren't well addressed by just doing that, and that you should have a more sophisticated governance strategy than what is promoted by Scrum. For example, a common risk is that your stakeholders don't agree on a common vision, so you might want to do something to get them to come to agreement early in the project before you get hot and heavy into construction. The implication is that you might want to have a checkpoint/ milestone review to validate this. Similarly another risk is that you don't have a viable technical strategy, so you might want to do something to prove that your architecture works (with working code) early in the project and then validate that this has happened as well. It is implying the need for another potential milestone/checkpoint review.

It is important to clarify the terms and make useful distinctions, or even better, fundamental distinctions. Since people will use these common terms in different ways, all you can do is be clear about your usage and message.

Posted in: Agile,Connecting Dots