¶Timeline

Every epic against the calendar. One bar each, filled as far as its issues are closed.

It is deliberately not the Gantt. That page draws issues, dependencies and scenarios, and lets somebody move dates to see what happens — a planning instrument for whoever owns the plan. This one answers a portfolio question for somebody who is not going to change anything: what large pieces of work are in flight, when are they meant to land, and which of them will not.

It is also the only page the Management role has that is not a report.

¶What a row shows

There is no label column. Each epic's title sits above its own bar and travels with it, which is what gives the whole width to time — and what makes a stack of bars read as a shape rather than as a table that happens to have bars in it.

Rows are earliest first, so each bar begins at or after the one above it.

¶Grouping

¶By person

The grouping a leadership group actually asks for: what is Arne working on, and is it more than a week holds. Each heading carries what a manager asks in the order they ask it —

ARNE BERG · 22 open · 1 overdue · 7d 7h · 1.7w · +5 unestimated · 8 epics

• Open and overdue are the direct answer to who is behind
• The hours are the estimates on their open issues, and the weeks figure divides those by the hours they actually have for plannable work, not their contracted week — somebody with a standing support rota does not have their whole week for this. See Cycles for where that number comes from
• Unestimated is counted apart, never folded in. Three unestimated issues on a plate is not a light plate, and an hours figure that quietly omits them makes somebody look free
• Machines are counted beside people, in the colour the rest of Félagi uses for them. An agent carrying ten issues is part of the picture

An epic appears under every person carrying work in it, and that repetition is the point: "what is Arne working on" has to show all of his epics whether or not somebody else is on two of them.

Opening an epic under a person shows their issues in it, not everybody's.

This grouping is restricted, to owners, admins and management — the read-people gate. Reading who is behind is a different kind of trust from doing the work or from running the agent workforce, which is the split the roles already draw. It is absent from the selector for anybody else rather than present and refusing, and asking for it in the address gets the default back.

¶The diamonds

Each one is a milestone: a name, a date and a status, set on the epic itself. See Working with epics.

Five per epic at most, and when there are more it is the five nearest today, with the rest counted as +N more at the end of the bar. Fourteen diamonds and fourteen overlapping labels is less legible than five and a number.

A label is given the width of the gap to its neighbours and truncated to fit; below about six per cent of the axis it is dropped entirely, because a two-character stub under a diamond is worse than the diamond on its own. The full name, status and date are always on the diamond itself, and the panel lists them in full.

¶Where an epic has no milestones

Its dated issues stand in — the child issues that carry a due date — drawn smaller and fainter, and named in the legend as what they are.

That is deliberate on both counts. Adopting milestones is not a cliff: the page is useful the day before anybody creates the first one. And the two are different kinds of thing — a milestone is a decision about the plan, a dated issue is the work that gets there — so they are never drawn on the same bar, and never in the same weight.

An epic that has milestones always shows milestones, even when they all fall outside the window. Otherwise the same bar would show two different kinds of mark depending on which window somebody happened to be looking at, under one legend.

¶A milestone past the end of its bar

Drawn where it falls, outside the bar.

The bar runs to the epic's own due date; a checkpoint dated after it is a plan that does not add up, and moving the bar to cover it would hide exactly that. An epic with no dates of its own takes its span from its milestones, so this only happens when somebody has set both and they disagree.

¶Inside an epic

The chevron beside a title opens it: the epic's own issues as thinner bars on the same axis, each with whoever holds it, its number and its title.

Issues that carry no dates, or fall outside the window, are counted under the bars rather than dropped — the same rule as the unscheduled epics, for the same reason.

Nothing is fetched for an epic nobody has opened. A portfolio view that read every issue in every epic in order to draw none of them would make the cost of this page the cost of the board, on the workspace least able to afford it.

¶The overrun tail

When an epic is past its date, the bar still stops at the deadline — that is what was promised — and a dashed red tail runs from there to today.

The difference between a chart that says late and one that says how late.

¶Health

The one judgement on the page, and the reason it is worth having. "In progress" is true of an epic for a month and says nothing.

Red is spent on lateness on this page — the late bars and the overrun tails — which is why today is drawn in the accent colour rather than in red as it is on the Gantt. Two readings in one colour on one chart is one reading lost.

Twenty-five points, not five. Work does not arrive evenly — an epic is often four weeks of building followed by a week in which everything closes at once — so a narrow threshold paints half the board amber every month and teaches everybody to ignore the colour.

¶Where the dates come from

An epic can carry a start date and a due date. When it does, the bar is what was planned.

When it does not:

1. One end only is enough. An epic with a deadline and no start is the commonest shape in every tracker, and it is drawn at its due date — we know when it must land and nothing else
2. From its milestones or its issues. An epic nobody dated is drawn across whichever of those carry dates, and the panel says (from its issues) rather than presenting a guess as a decision. A milestone is a date on the plan, so an epic with three of them is scheduled even if nobody filled in the epic's own dates
3. Neither — it appears under Not scheduled below the chart

Nothing is dropped for being awkward. The unscheduled epics are listed by name, because a management view whose omissions are invisible is worse than no view: work nobody has committed to a month is exactly what somebody wants to be asked about. The same is true of the count of epics outside the window, which is stated under the chart.

¶The window

Three zooms, each aligned to whole units so the first column is a column and not a stub:

The axis has two tiers, coarse over fine, so a column can be a week without the header becoming a list of dates nobody can place in a year. The year is said on the upper tier only, on the first column and again wherever it turns over.

Today is a dated pill on the lower tier rather than only a line: a line alone makes the reader count columns to work out which day it is. A column label that would sit under the pill is dropped.

Columns are as wide as the time they cover — February is shorter than March, and a chart whose columns are all equal puts the bars in the wrong place to make the header tidy.

A bar that runs past an edge is squared off there rather than ending in mid-air on a date that means nothing.

Every control is in the address, so a link to a particular window is a link somebody can paste into a board paper.

¶Clicking a bar

A panel, not a link to the issue. The role this page exists for has no issue pages at all, so a link would answer 403 for the people most likely to press it.

The panel carries the project, the status under the workspace's own name for it, the health, the dates, who owns it, the progress, and how many people outside the company are following it. That last number is what makes an epic feel different from an issue: somebody is waiting for it who cannot see this screen. See Keeping clients told.

Anybody who does have the board can reach an epic from Epics.

¶CSV

Export on the Reports index gives every epic with its dates, progress, health and owner — the whole portfolio, not the window on screen. A spreadsheet has no viewport to scroll, and an export that quietly dropped the unscheduled epics would be missing the half somebody most wants in a column they can sort.

¶What it does not do

• Nothing on it can be edited. No dragging dates, no scenarios, and no editing a milestone from here. That is the epic's own page
• No dependencies. Arrows between epics are on the Gantt, between issues
• No initiatives. Project and person are the groupings, because they are the two levels that exist above an epic
• No filtering. Every epic in the workspace is on it. Narrowing by project, label or cycle is what Reports are for