Gantt

Work laid out against time, grouped by project or by epic.

It shares everything with Reports — the same filter, the same saved views, the same CSV export. A chart is a report that happens to be drawn.

What a row shows

Two bars, not one. Most charts draw the plan and stop, which is why nobody believes them by the third week. The green bar is built from what was recorded — hours logged, status changes, agent runs — so the gap between promise and reality is visible without anybody having to report it.

Where the green bar begins and ends

It begins at the earliest of three recorded facts: the first day hours were logged, the moment the issue first entered a status somebody works in, and the first agent run. The earliest rather than a preferred one, because an hour logged before anybody moved the card is still work, and it belongs inside the bar.

It ends at closed_at — the moment the work finished — extended to cover any hours logged after the closing. An open issue's bar stops on the last day worked rather than running to today: running it to today would claim every open issue is being worked on right now.

Neither date is updated_at, and both used to be worse. The finish read updated_at, so editing the title of an issue closed in March moved its bar to today and a bulk write moved every bar in the chart. The start read the first agent run, which exists only for work a machine did — so every issue a person worked on began, according to the chart, at whatever its planned start happened to be.

Where the dates come from

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

When it does not, the bar is derived, in this order:

1. Start date, if set
2. Due date minus the estimate, working backwards — the only defensible guess when somebody has said when a thing is due but not when it begins
3. When work is recorded as having begun, if anything recorded it
4. Created date, as a last resort

A bar with no start date and no due date is drawn dashed. It is a guess from the estimate, and it says so rather than looking like a decision somebody made.

Estimates convert at eight hours to the day, the same as everywhere else in Félagi.

Progress

Spent against estimate, capped at 100%. An overrun is a fact about time, not about progress — a bar past 100% would have to draw outside its own plan, and the time report is where an overrun belongs.

Where there is no estimate, status is the only honest signal, and it is a coarse one: in progress reads 50%, in review 75%, closed 100%. It does not invent precision it does not have.

Grouping

By project puts each project on its own row, with a bar spanning its issues. Issues without a project are collected under No project.

There is no diamond on a project row. A project carried a target date once and no longer does — it is a system, and it does not finish. Dates belong to epics.

By epic does the same for epics. The epic itself is not drawn as a row: it is a container, and drawing it beside its own children would double every bar it holds.

Group rows collapse.

The period picks the window

In front of a Gantt, "show me September" means scroll there, not filter by created date. So the period sets the visible window, and any issue whose work overlaps that window appears — whenever it happened to be created.

Choose All time and the data sets the edges instead. Today is always inside the range then, because a chart of finished work that floats free of the present cannot tell you whether it is late.

The scale coarsens as the span grows: days up to a month, weeks up to six months, months beyond that.

Dependencies

Hierarchy groups work; a dependency orders it. Add one from an issue's properties panel — Wait for… — and it appears as a line on the chart.

A lag adds days of waiting after the predecessor: a review window, a deploy freeze, paint drying.

Three links are refused: an issue waiting for itself, one across workspaces, and anything that would close a loop. A cycle in a plan is an infinite loop in a calculation, and the calculation is the only reason to record dependencies at all. The candidate list never offers one that would.

What they change

Scheduling. The forward projection now starts an issue at the later of three things: when its assignee is free, when it was planned to start, and when everything it waits for is done. Predecessors are scheduled first, whoever owns them, so a person's third issue can be blocked by somebody else's first.

It walks day by day, and a day can be empty. Recorded absence — a holiday, an illness, a public holiday — takes that day's capacity out, so the projection steps over it: two days of work starting Monday finishes Tuesday, and with that week booked off it finishes the Tuesday after. See Absence.

With enough leave there is no finishing date to draw, and the projection says so by drawing none rather than by walking for ever.

The showstopper panel names the cause rather than the symptom:

Waiting on late work — ACM-3 cannot start until ACM-2 is done, which lands it 7 Aug — 3 days past 4 Aug.

Cascade. Each late issue reports how much is stuck behind it, transitively. "What is late" is not the interesting question; "what does this cost me" is, and the answer is the size of the tail.

On the chart

Lines are drawn between bars within a group. A line from the bottom of one section to the top of another crosses everything in between and reads as noise, so cross-group links stay visible on the issue itself.

A line turns red and dashed when the successor's bar starts before the predecessor's ends. That is the picture of a plan that cannot happen, and it is worth seeing without reading any dates.

The critical chain

A backward pass from the last projected finish gives every issue its slack: how many working days it can drift before the whole thing lands later. Slack zero is critical, and those rows carry a yellow marker.

Critical chain — 4 issues with no slack, delaying any of them moves the end date. Everything lands 12 Aug 2026.

Two things make this different from the chain a textbook would draw.

It is capacity-constrained. The forward pass it reads from already accounts for who is busy, so a person being overloaded puts work on the critical chain exactly as effectively as a dependency does. That is the honest answer: if two issues sit on one person's queue with no link between them, the second one still cannot move without moving the end.

It is computed, not declared. Nobody marks work as critical. It becomes critical by having nowhere to go.

Dragging, and moving dates onto capacity

Inside a scenario you can edit, bars are draggable. A bar snaps to whole days, and dropping it proposes the move — the same proposal the row menu's push a week would make. Outside a scenario nothing is draggable, because a plan should not change because somebody's finger slipped.

Move dates onto capacity takes the projection — which already knows who is busy and what waits for what — and writes it back as proposed dates. Per person from the queue strip, or for everything at once.

It is not resource levelling in the textbook sense: nothing is reassigned and no queue is reordered. It answers one question, "when can this actually happen", and puts the dates there. Issues already sitting on achievable dates produce no proposal, so the scenario holds only what really moves.

And it proposes. An algorithm that silently rewrites everybody's dates is a tool people stop trusting the first time it surprises them, so it needs a scenario to write into and refuses without one.

When would this land, if each of them took it?

On any issue: Assignee → When would this land?

The projection has always been able to answer this and was never asked. It schedules every assignee's open work forwards through their real capacity, so "given what Arne already owes, the 14th; give it to Freya and it is tomorrow" is a sentence it already contains — and the assignment that decides the date was being made from a name in a dropdown.

Freya Lund      soonest    nothing in front of it                  8 Sep
Arne Berg                  3 issues in front · 1w 2d              21 Sep
Bragi                      nothing in front of it                  8 Sep
Kari Vold                  Committed to standing work for the whole week   —

This is the comparison no other tracker can make, because no other tracker has the machines in the capacity number. An agent's weekly hours count exactly as a person's, so a queue of one is a queue of one whoever is standing in it.

Every date travels with the argument for it, which is the rule the health rule and the cost report already follow:

What is in front of it. A date on its own invites "why is Arne slow" rather than "Arne is carrying eleven days of work".

What the date would cost. Tomorrow is not a good answer if it puts two other things past their dates, so the row says which and by how much. Whatever was already late is not counted — it stays late whoever takes this, and blaming this assignment for it would make every candidate look ruinous.

Why there is no date, when there is none. A candidate with no plannable hours is named with the reason rather than dropped: a shorter list presented as the whole field is a comparison somebody acts on without knowing who was left out.

Three things worth knowing.

Due-date order decides the answer. Work is scheduled in the order somebody actually works in when they are behind, so putting a date on this issue moves it up every queue — and an undated one lands behind everything already promised, and displaces nothing. The same issue can be tomorrow or the 21st depending only on whether it has a deadline.

An unestimated issue gets no dates at all, and says so. With nothing to schedule it lands the moment anybody picks it up, identically for everybody — and a screen of matching dates reads as a comparison that came out level. It is not level, it is unknown.

Where two would land it on the same day, neither is marked soonest. They are level, and badging whichever sorted first would invent a distinction the projection did not find.

It is the Gantt's own projection, asked once per candidate — not a second, simpler calculation. Two screens giving two dates for one issue would leave nobody able to check either.

Making it the promise

Each row with a date carries Promise this — or Take it and promise for a candidate who is not holding the issue, because a date projected through Freya's queue is not a promise about anybody else. One click writes the projected finish to the due date, and takes the assignment with it.

Until this existed the date could only be read and then typed into the sidebar by hand, which is how a schedule and a due date come to be two different numbers. Once they are, the schedule is a curiosity and the due date is a guess.

Two things about it:

The date is recomputed when you click, not taken from the screen. A finish arriving from a browser is a date anybody can choose, and the whole value of the button is that the number is the schedule's rather than the clicker's.

Promising a date changes these dates, including this one. Work is scheduled in due-date order, so the issue moves ahead of everything due later — which is stated on the flyout rather than left as a surprise.

It is recorded as a date that came from the projection, not as somebody typing one. Six months later the difference between we committed to the schedule's own answer and somebody picked a Friday is the whole of what the promise was worth — and Throughput reads exactly that back as did it land when we said.

Not there yet

• No automatic levelling. The projection will tell you which pair of hands makes this issue land soonest and what that costs (above); it will not move the work for you, or rebalance a queue on its own. Both remain your decision, taken on the issue or through a scenario.
• It knows nothing about the work. The dates are capacity, queue and dependencies. Whether a candidate is the right one to do this particular thing is a judgement the projection cannot make and does not pretend to.
• Two link types, finish-to-start and start-to-start. The other two exist in project management textbooks and rarely anywhere else.
• No baseline snapshots. A scenario compares against the plan as it is now, not against what it looked like at the start of the quarter.
• No stored projections. A projection is a function of the capacity on the day it was made — the queue, the leave, the standing work — and none of that is kept. So accuracy is measured against the due date, which is the only forecast that was written down, and that is why committing one matters.

What-if scenarios

A scenario is a copy of the plan you can move around. Nothing is written to a real issue until you apply it, so three people can argue about a schedule while the actual schedule stays exactly as it is.

Pick one from the plan selector at the top of the chart, or create one. While a scenario is active:

• Row menus offer push a week, push a day, pull a week forward and reassign
• Pushing moves the start and the due date together. Pushing a deadline without pushing the start is not a plan, it is a wish that the work will shrink
• Every showstopper that is going to be missed gets a Move to 14 Aug button, taking the date the projection already worked out
• The old date stays on the chart as a hollow diamond, so you can see what moved

Did it help?

The scenario bar carries the only number that matters:

critical  10  →  8   −2

Showstoppers are recalculated through the scenario and compared against the real plan. A what-if that cannot tell you whether it helped is a drawing.

Applying

Apply writes every change into the plan and closes the scenario, which then becomes history rather than a draft.

A change whose underlying value moved since it was proposed is skipped and reported, not applied. Quietly overwriting a colleague's edit with a week-old proposal is the behaviour that makes planning tools untrustworthy. Those proposals are marked in the bar before you press anything.

Discard throws the scenario away. Nothing was ever written, so there is nothing to undo.

Sharing

Private by default. A shared scenario can be opened by anyone in the workspace and changed or applied only by whoever made it.