Timeline

Every epic against the calendar. One row each, and it answers four things: which epic, which period, which status, and how old the status is.

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

Three cells: the epic on the left, time in the middle, the status on the right.

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

Above the chart, a count per status and — when there is one — how many of those colours nobody has revisited in a fortnight.

Grouping

Every group, including the empty ones. A project with nothing planned used to be left off the page, which reads as no such project rather than nothing planned — and a portfolio review is as interested in the empty rows as the full ones. The same in By person: somebody with an empty plate had no heading at all, which looks identical to having left the company. "Who has nothing on" is the same question as "who has too much", asked from the other end.

Finished and cancelled projects stay off. A shipped project is not a gap in the plan, and listing every project that ever existed would make this page longer each quarter and emptier each time.

Alphabetical, and nothing else. It used to lead with whatever was most off track, which sounds right and is wrong for a page somebody reads every week: the order changed under them as the statuses changed, so finding a project meant scanning rather than knowing where it lives. What is late is still on the heading, as a count, and in the totals above the chart.

Groups open and shut

Everything arrives collapsed in By project and By person. Sixteen projects and seventeen epics as one wall meant the first thing anybody did was shut most of it.

• One press on a heading opens or shuts that group
• Expand all / Collapse all does the lot. Not offered in Flat, where there is one group and folding it would be a control for nothing
• A shut group keeps its summary — that is the point of shutting it — and draws one bar spanning everything inside it, coloured by the worst status in the group. Four greens and a red is a project with a red in it, and a colour averaged to amber would hide the only row worth opening
• A group with nothing in the window says "No epics in this period" rather than showing an empty strip, which reads as a page that failed to load

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, with the rest counted as +N at the end of the bar — and that count includes milestones outside the window, because a checkpoint next year is part of the plan whichever months are on screen.

No names under the bar. The full name, status and date are on the diamond itself, and the panel lists them in full. A label per checkpoint needed a row half again as tall, on a page whose whole argument is that it can be read in ten seconds.

An epic with no milestones shows a bare bar. It used to fall back to drawing the dated issues inside it, smaller and fainter; those are the work rather than checkpoints, and issue dates left this page altogether — see what it does not do.

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.

Status

Four, and a person sets them. Not worked out from anything.

There is no finished. An epic that is done leaves the page by being done, which is a fact the board already holds.

Why it is not calculated

It used to be. The rule was does the estimated work left fit in the working days left, painted green, amber or red — honest arithmetic, and it answered the wrong question.

An estimate nobody revises makes an epic turn red because it was underestimated in January, not because it started slipping in March. Those are two different sentences and one derived number cannot tell them apart, so it told a director the wrong one at the moment somebody was deciding something. A status that gets read out in a meeting has to be a judgement somebody will stand behind.

That calculation still exists, on the Gantt, where the person reading it owns the plan and knows what the estimates are worth. It is not duplicated here.

Setting one

A press on the status in the row. Four items, one click, no dialogue — the whole argument for a manual status is that keeping it current has to cost nothing.

Anybody who may write issues can set it. Management reads it: the role exists to read the work rather than to do it, and this is part of the work.

How old it is

Every row says when the status was last set, and says never set rather than ageing a judgement nobody made.

After a fortnight the line turns amber and the top of the page counts how many have gone that way. Nothing about the status itself changes — a colour that quietly rewrote itself after two weeks would be a derived status again, with a worse rule.

Green set six weeks ago and green set this morning are the same pixel. That is the failure a manual status brings with it, and saying the age out loud is the only honest fix.

The reason behind it

The panel takes an optional note with the status: why. "Why is it red" has a different answer every time, and the meeting is the worst place to reconstruct it. Written while it is still known, it takes ten seconds.

It is shown in the panel with who set it and when, and it is in the CSV.

Where the dates come from

An epic carries a start date and a due date, both set on its own page. When it has both, the bar is what was planned — and the status beside it is somebody's view of whether that still holds.

An epic has no estimate of its own. The issues inside it are estimated; a second figure on the epic would be two answers to how long the same work takes, with nothing to say which the reports should believe. Epics that carried one when this changed had it turned into a start date, since that is what the Gantt was already inferring from it.

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:

It opens one period before today. The page used to start at the current week, month or quarter, so anything begun in the one before arrived already clipped at the left edge — a bar with no beginning, which reads as work that has always been running. Most of what a portfolio review is about started before the review.

One period, not two: six months at the middle zoom, and spending two of them on the past leaves four for the plan. Further back is what the arrows are for.

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 status with who set it, when, and their note; the project, the owner and the dates; the progress as a fraction and a percentage; the issues inside it, closed first with a tick and open below, without dates; the milestones; 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 may write issues can set the status from here too, with a note. Twelve issues are listed and the rest counted.

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, owner, and its status with the day it was set, who set it and why — 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

• The status is the only thing on it that can be changed. No dragging dates, no scenarios, and no editing a milestone from here. That is the epic's own page
• No issue dates. The issues inside an epic used to open as thinner bars on the same axis, and an epic without milestones drew its dated issues as faint diamonds. Both are gone: dates at issue level are noise in a portfolio overview, and they are on the Gantt for anybody planning against them. The panel lists what is inside an epic without them
• 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