Leadership walkthrough · Chapter 6 of 8
Releases and milestones
A release is a version the team ships: a name, a date and the work in it. A milestone is a date the project has promised: go-live, UAT sign-off. Milestones keep their committed baseline, so leadership always sees slippage against what was promised, not against the latest plan.
First, the workstreams
Card Checkout's workstreams are its epics, so each release and milestone must name one. Ravi creates the three epics before anything else:
- In the project, open Backlog and choose New work item.
- Type: Epic. Title: Payments. Create it, then repeat for Checkout UI and Fraud rules.
Loyalty App is one workstream, so it needs no epics before planning: its releases and milestones belong to the whole project.
Releases
- Open Plan › Releases and choose New release.
- Fill it in.
- Name: 1.0. In an each-epic project the name is unique within its workstream, so Payments and Checkout UI can each have a 1.0.
- Workstream: Payments (only in each-epic projects).
- Start and Release date: when work starts and when it is planned to ship.
- Description: what the release is for.
- Choose Create release.
Every open work item sits in its workstream's next planned release: the unreleased one with the earliest date. A finished item stays in the release it finished in. Shipping a release moves its unfinished items on to the next one. Each item shows its release as a read-only field.
On release day
From the release's ⋯ menu choose Release. Its unfinished items move on to the next planned release, and the weekly status shows the release as shipped without anyone retyping it. Archive tidies old releases away.
Milestones
- Open Plan › Milestones and choose New milestone.
- Fill it in.
- Name: UAT sign-off.
- Workstream: in each-epic projects, required. Reports then name it: Payments: UAT sign-off.
- Committed date: the date promised to the client. This becomes the baseline.
- Forecast: optional, the lead's current estimate.
- Linked to: optional, a release, an epic or feature, or a sprint. Its date stands in for a forecast when there is none.
- Choose Add milestone.
When dates move
- The forecast moves freely. Edit the milestone and change the forecast. The page measures the expected date against the baseline and shows the milestone as on track, at risk or overdue.
- The commitment moves only by Re-baseline. From the milestone's ⋯ menu, choose Re-baseline, give the new committed date and a reason (Client moved UAT by two weeks). The old date stays on record.
- When it happens, Mark achieved. It records the actual date: achieved on time or achieved late.
- A milestone that was re-baselined can't be deleted, only cancelled, so recorded slippage survives.
The page's summary shows open milestones by health, the worst variance, the on-time rate and the number of re-baselines. A milestone whose expected date slipped at each of the last three weekly readings is marked Still moving. On a fixed-price project like Card Checkout, these milestones are what the schedule rating, and so overall health, is judged on.
Areas
Plan›Areas holds the project's area paths: which part of the product work belongs to. Sprints say when; areas say what. They are optional; teams imported from Azure DevOps bring theirs.
The plan is set. Now the work itself. Chapter 7.