Planning a Roadmap

How work gets onto the roadmap

The roadmap does not plot tickets. It plots milestones — every milestone in every live project, whether or not anybody has said when it runs. Four steps:

1. Make the milestone here. Every project has its own row down the left of the roadmap; the + beside its milestone count writes a new one. This is the only screen that shows every project's milestones against the same axis, which is why it is where they are made, renamed and retired — the … on a bar opens the rest.
2. File tickets under a milestone. Open a ticket and pick one, or set it when you create the ticket. A ticket with no milestone is perfectly valid work — it just won't show up here.
3. Give the milestone a start and end date. That is what turns it into a solid bar in the right place. Until then it is drawn dashed, running the whole width of the roadmap — still there, still draggable, just not yet claiming a date anybody chose.
4. Drag it. Grab the middle of a bar to move it, or either edge to stretch it. A drag lands on the day under the pointer, which at this zoom is a rough aim — the milestone's own Starts and Ends fields are where you say a date exactly.

Hover a bar for the … at its right end: edit the milestone's name, description, owner, status and colour, open the work filed under it, or delete it. Deleting a milestone leaves its tickets exactly where they are — a milestone is a grouping, not a container. All of it is for people who run the project; everybody else reads the bars.

Dates on a quarter axis

A milestone holds two days — when it starts and when it ends — and the columns it is read against are quarters. Those are two different things, on purpose. The dates are what the record says; the quarters are the scale you read a year at, and a bar is placed along the columns it crosses rather than filling them. So a fortnight in March is a short bar a third of the way into Q1, not a block covering the quarter.

Set the dates on the milestone when you know them. Drag the bar when you are moving things around and only care roughly where they land — it writes real dates either way, so a bar nudged across two columns comes back with days you can then tidy up on the milestone itself.

Day-level commitment still happens in goals, where a two-week window is something a team can actually hold. A milestone's dates are the shape of the thing, not a promise about any particular week inside it.

Milestones missing a date

You do not have to know both ends. A milestone with an end date and no start has been running since before anybody was looking; one with a start and no end runs until somebody says otherwise. Either way the bar is drawn all the way to the edge of the window on the open side, and it keeps reaching that edge however far you scroll — so “ships by March” reads as months of work arriving in March, not as a mark on the 31st.

A milestone with neither date runs both ways, so it fills the roadmap end to end. That is the same rule twice over, and it is the honest picture: nobody has said when this starts or when it finishes. The bar is dashed, which is what tells it apart from a milestone somebody genuinely scheduled across two years.

A squared-off end is how a bar says the work carries on past there. A rounded end is a real date. Dragging the middle of a bar with one date moves the date it does have and leaves the open side open; to pin that side down, grab the squared-off edge itself and pull. Drag the middle of a dashed bar and it contracts to a month under your pointer — that is the quickest way to get an unscheduled milestone onto the calendar, and you can stretch it from there.

How much of it is done

Each bar fills from the left with the share of its tickets that are marked Done, and carries that percentage beside the milestone's name. It is the same figure the milestone's own page and its project's Milestones table show, so a bar answers “is any of this actually happening” without you opening anything.

Cancelled tickets do not count — neither as work done nor as work outstanding. Work the team took back is not a shortfall, so a milestone whose every remaining ticket has shipped reads 100% even with cancelled tickets still filed under it. A milestone with nothing left to measure shows its ticket count instead of a percentage.

Where you are

A red line runs down the roadmap at today, with a dot at the top — the same marker the calendar's day and week views draw across the current hour. It is the thing that makes the bars mean something: a milestone whose end is behind the line has not finished on time, and one whose start is behind it should already be underway.

Scroll far enough forward or back and the line goes, because today is no longer on screen. A Today button appears beside the arrows to bring you back.

Reading a roadmap

• Each row is one project, and each bar within it is a milestone. A project with several bars in the same quarter is doing several things at once — which may be fine, or may be the thing to notice.
• Read down a column, not just across a row. Everything in the same quarter is what the company is committing to at the same time. That is the question a roadmap exists to answer.
• An empty quarter is a real answer. A roadmap with every quarter full to the edge for the next two years is a wish list, not a plan.
• A long bar at 0% is worth a conversation, and so is a bar at 90% whose end is still two quarters out. The dates say what was planned; the fill says what has happened.

How far out to plan

The default view shows six quarters, which covers the rest of this year and most of the next. That is about the limit of useful planning for most teams: near quarters hold specific milestones, far ones hold intentions.

Widen the window when you need to show a longer arc, and narrow it when you want the next two quarters to fill the screen. It changes what you see, never what is stored.