# Milestones

> Mark the delivery points that matter and track everything hanging off them.

> For the complete documentation index, see [llms.txt](https://helpdesk.orangescrum.com/llms.txt).

Source: https://helpdesk.orangescrum.com/guide/cloud/views/milestones

---
A milestone is a dated point a project must reach — a release, a client demo, a
regulatory deadline. Tasks are assigned to milestones so you can see what is
outstanding for each.

Available on every tier, including the
[Community Edition](https://helpdesk.orangescrum.com/guide/community/usage/tasks#milestones).

## What makes a good milestone

- **Externally meaningful**: Something a stakeholder would recognise: "Beta launch", "Client sign-off".

- **Has a real date**: A milestone without a date is a category.

- **Verifiably done**: You can say yes or no. "Improve performance" is not a milestone.

- **Few of them**: Three to six per project. Twenty milestones is a task list.

## Milestone or sprint?

They solve different problems and are often confused:

| Milestone | Sprint |
| --- | --- |
| A **deliverable** | A **time box** |
| Date set by the outside world | Fixed length, repeating |
| Can span several sprints | Always the same duration |
| "v2.0 ships 14 March" | "Sprint 7, two weeks" |

Teams running Scrum use both: sprints for cadence,
milestones for the commitments the business made.

## Setting them up

**Start from commitments**

    List what you have already promised, and to whom. Those are your milestones.

**Give each a date and an owner**

    An unowned milestone slips quietly.

**Assign tasks**

    Every task that must be done for that delivery. This is the part that makes
    a milestone useful — it turns a date into a scope.

**Look at what's left**

    The gap between remaining work and remaining time is your actual status.

## Tracking

The milestone view shows completion, what is outstanding and what is at risk.
Milestones also appear as markers on the
[Gantt chart](https://helpdesk.orangescrum.com/guide/cloud/views/gantt-chart).

> **Milestone progress can mislead**
>
> "80% of tasks complete" says little if the remaining 20% is the hard part.
> Look at *which* tasks are outstanding, not just how many.

## When one is going to slip

Deal with it early — the options narrow as the date approaches.

**Say so as soon as you know**

    A month's warning gives options. A day's warning gives excuses.

**Separate must-have from nice-to-have**

    Most milestones have both. Cutting scope is usually better than moving the
    date.

**Check the critical path**

    On Premium, the [critical path](https://helpdesk.orangescrum.com/guide/cloud/views/gantt-chart#critical-path)
    tells you which delays actually matter.

**Move the date if you must — once**

    A milestone that moves three times has stopped meaning anything.

## Closing one

When it is delivered, close it. Then look back:

- Which tasks were missed at planning time?
- Which estimates were furthest out?
- What slipped, and why?

That is the input that makes the next milestone's estimate better. Feed it into
your [project templates](https://helpdesk.orangescrum.com/guide/cloud/projects/project-templates).

- [Gantt chart](https://helpdesk.orangescrum.com/guide/cloud/views/gantt-chart): Milestones on the timeline.

- [Sprints](https://helpdesk.orangescrum.com/guide/cloud/agile/sprints): Iteration cadence alongside milestones.