User guide · Projects
Milestones and releases
Both sit under Plan in the project's sidebar. A milestone is a date the project has committed to. A release is a version it ships. Reading needs project read access; changing needs Lead or Owner.
First, which workstream
In a project whose Workstreams are Each epic, every milestone and release belongs to one epic, so create the epics first. In a project that is one workstream, everything belongs to the whole project and there is nothing to pick.
Milestones
Adding one
- Open Plan › Milestones and choose New milestone.
- Name, such as Go-live or UAT sign-off.
- Workstream, in each-epic projects. Reports then name it: Card checkout: UAT sign-off.
- Committed date: the date promised. It becomes the baseline.
- Forecast (optional): the lead's current estimate.
- Linked to (optional): a release, an epic or feature, or a sprint, whose own date stands in for a forecast when there is none.
- Choose Add milestone.
Keeping it honest
| Action | Where | What it does |
|---|---|---|
| Edit | Row's ⋯ menu | Change the name, forecast, link or description. Not the committed date. |
| Re-baseline | Row's ⋯ menu | Moves the committed date. Asks for the new date and a reason, and keeps the old one on record. |
| Mark achieved | Row's ⋯ menu | Records the actual date: achieved on time or late. Reopen undoes it. |
| Cancel milestone | Row's ⋯ menu | Keeps it on record as cancelled. |
| Delete | Row's ⋯ menu | Only for a milestone never re-baselined, such as one added by mistake. |
Each milestone's expected date is its actual date, else its forecast, else its linked item's date, else the baseline. It is measured against the baseline and shown as on track, at risk, overdue, achieved on time, achieved late or cancelled.
The summary at the top gives the open count by health, the worst variance, the on-time rate and the number of re-baselines. A milestone whose expected date was later at each of the last three weekly readings is marked Still moving.
Releases
Adding one
- Open Plan › Releases and choose New release.
- Name, such as v1.0. In each-epic projects a name is unique within its workstream, so pickers show 1.0 · Card checkout.
- Workstream, in each-epic projects.
- Start and Release date: when work starts and when it is planned to ship.
- Description: what the release is for. Then Create release.
How work gets into a release
Nobody puts work in a release by hand. Every open item sits in its workstream's next planned release: the unreleased one with the earliest date (undated ones last, in the page's order). A finished item stays in the release it finished in. Each item shows its release as a read-only field.
Shipping and tidying
- Release, from the row's menu on the day: unfinished items move on to the next planned release, or wait for one to be added.
- Archive old releases; Unarchive brings one back. A released release with items can't be deleted, only archived.
- Order releases by dragging; undated ones follow that order.
The weekly status reads a workstream's release details from here, so a shipped release shows its actual date without anyone retyping it. A milestone can be linked to a release, so its date lives in one place.
Areas
Plan›Areas holds the project's area paths, a tree that says which part of the product work belongs to. Filtering by an area includes everything under it. Anyone on the project reads them; editing needs a lead.