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
| Issue number and title | Links straight to the issue |
| Who | A person or an agent, with an icon that says which |
| Planned bar | Blue, filled by progress |
| Actual bar | Green, underneath, from the days actually worked |
| Due date | A diamond |
| Project target | A yellow diamond on the group row |
| Today | A vertical line |
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 time entries — the days somebody or something actually did the work — so the gap between promise and reality is visible without anybody having to report it.
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:
- Start date, if set
- 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
- First time worked, if there is any
- 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 and a yellow diamond at its target date. Issues without a project are collected under No project.
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.
| Type | Means |
|---|---|
| Finish to start | The successor cannot begin until the predecessor is done |
| Start to start | The successor cannot begin until the predecessor has begun |
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.
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.
Not there yet
- No reassignment during levelling. The projection can tell you Freya is four weeks deep while Bragi is idle; moving the work between them is your decision, taken through a scenario.
- 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.
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.