Timeline Tab — Feature Guide

What it's for

The Timeline tab draws every epic and issue as a bar on a calendar, for the project chosen in the project selector, or for every registered project at once.

The bars are not typed and they are not dragged into place by a planner. Each bar sits where Project Commander's own scheduler says the work lands — worked out from the size of the job, who it is assigned to, the hours that person really has, the share of their time they give to work, their booked time off, the public holidays on their calendar, and what blocks what. Change an estimate, a person, a date or a dependency and the whole chart redraws itself.

That is the difference from every other Gantt chart in the Jira world. A dragged bar is only as true as the last person who dragged it, and somebody has to keep dragging it for the picture to stay true. A bar here keeps working itself out.

It is intended for project managers, engineering managers and programme leads who need to show a plan as a picture — to a stakeholder, in a steering meeting, or on a screen share — without maintaining a second plan by hand.

The three cards above the chart

Three cards run across the top of the tab, in this order: On Pace?, Delivery Forecast and Target Date. They are the app's own cards, drawn by the same components the Dashboard and What-If tabs use, reading the same numbers. A figure on this tab and the same figure on another tab can never disagree, because there is only one calculation behind both.

What this chart is telling you

Beneath the cards sits a folding notice headed What this chart is telling you. It starts folded, showing the number of notes and the first three of their headings; opening it gives the full list.

It says in plain words what the picture is showing, so the chart is never the only place a fact appears. Depending on what is on screen it carries:

• That the bars are worked out and not typed, and which Work starts rule is in force. This note is always first.
• How many issues could not follow the Work starts rule and fell back to as soon as possible, because their epic has no start date, or because they have no due date to work back from.
• How many issues run past the date they are committed to, and by how many working days (the first six named).
• Who is over capacity before the target date: the work they have to finish by then needs more working days than they are there for. Their bars carry a red ring.
• Work due after the target date that is not counted against it: whose it is, and how many working days of it.
• How many working days the delivery forecast allows beyond the last issue on the chart — or, when the last issue finishes after the delivery forecast, that it does, by how many working days, and why the two differ.
• With more than one project on screen under Shared capacity: how many projects there are, that there is one schedule, and who works across more than one of them.
• With a baseline chosen in Show baseline: the baseline's name and when it was captured, how far the forecast has moved, which issues now hold the finish date, and how many issues moved, were added or were removed.
• Each issue blocked by work that comes later, named, with both sprints: "DEMO-34 in Sprint 7 waits on DEMO-41 in Sprint 8".
• Each circular dependency.
• Issues nobody has estimated: they are drawn as a diamond at the date they would start, and the first six are named.
• Issues that cannot be timed at all because the person holding them has no capacity set on the Team & Capacity tab — no hours a week on a time project, no capacity in points typed on a points project; these are not on the chart, and the note names the people.
• Whenever the plan has a critical chain: how many issues are on it, how many working days of work that is, and which of the two things holds it together.
• In a project that uses sprints: how many issues in no sprint are on the chart with Include backlog ticked, or how many sit in no sprint and are not drawn with it unticked.
• For a project with Sprint Mode off: that the project has no sprints, that its work comes from the Issue filter, that the columns are its own planning periods, how long each one is, and what is hidden as a result.
• Where the tab can write to Jira: that the Start Date column is the date held in Jira, that editing it writes that field, and how many issues on screen carry one.
• Everybody's real availability — hours a week, the share of their time, booked time off and public holidays — and each person who is not at full pace between now and the target date, with the reason.
• How many bars are placed by a date somebody typed rather than worked out, how many carry a typed start date that is not what places them, and how many typed dates are not yet written to Jira.
• With No grouping, by due date chosen and no sort on: that the list is earliest due date first, that an issue with no due date of its own is due at the end of the sprint it is in and one in no sprint takes its epic's date, and how many have none of the three.
• With a sort on: which column, which direction, and that it applies inside each band.

The control row

A row of controls sits between the notice and the chart. Left to right:

• Shared capacity — see More than one project at once below. Greyed out until a second project is registered.
• Work starts — the rule for when an issue may begin (see Where the work starts).
• Show baseline — offered once the project has a saved baseline (see Show baseline).
• Critical chain only — see The critical chain.
• Include backlog — in a project that uses sprints, and not under Shared capacity. Ticked, issues that sit in no sprint are scheduled with the rest. It is the project's own setting, the same one the Dashboard, Scope and What-If tabs read, so ticking it here ticks it on those too.
• At the right-hand end, where the tab can write to Jira: Fill in due dates, Discard changes and Update Jira (see Editing on the chart).
• The gear, View settings (see below).

The chart

Columns

Columns are the project's open sprints, in calendar order, each headed with its name and its start and end dates; the active sprint's heading is highlighted. There are no projected sprint columns after the last planned sprint: the calendar carries on past it without headings. In a project with Sprint Mode turned off, the columns are that project's own planning periods (Period 1, Period 2 …), each as long as its Period Length, starting from the Monday of this week.

When several projects' sprints overlap, a heading that clashes with another goes on a line of its own. When that would need more than three lines of headings, the chart counts weeks instead, and a note beside Scale says counting weeks: these projects’ sprints overlap.

Scale and Zoom sit together in the strip along the bottom of the chart, at its right-hand end. Scale chooses Sprint (it reads Period in a project with Sprint Mode off), Week or Month; zoom is a slider with a minus and a plus either side of it, and the percentage beside it (40% to 300%). The chart opens scrolled to today.

The key, along the left of that same bottom strip, names only the marks actually drawn at that moment.

What is drawn on the calendar

• Today — a dashed vertical line, labelled Today in the heading strip.
• The target date and the forecast date — a purple T pin and a red P pin, carrying the same dates as the Target Date and Delivery Forecast cards above.
• The likely range — a light shaded band from the optimistic to the pessimistic finish date, which is the "likely" figure on the Delivery Forecast card.
• Past the target — hatched shading from the target date onward.
• Epic spans — with the chart grouped by Epic, a thin dark bar on each epic's own row from its first issue's start to its last issue's finish. The stretch that runs past the epic's due date is drawn in red, so an epic that overruns says so in its own bar.
• Issue bars — from forecast start to forecast finish, blue, with the size written inside, the done share filled in darker from the issue's own progress, and finished work in green. Finished work is drawn ending yesterday.
• Work placed by a typed date — drawn striped in yellow, so a date somebody chose is never mistaken for one the schedule worked out.
• Work with no estimate — a diamond at the date it would start, with no length, because nobody has said how big it is.
• The committed date — a downward arrowhead drawn at the end of the bar of every issue that has a due date; hovering it gives the date the issue is committed to. Where the bar runs past that date, the days late are measured and labelled on the row: a red line from the committed date to the bar's end, with a tick at each end. The label sits just below that line, inside its own row (rows are 52 px tall by default, since 2026-09-14, so the label fits under the bar without touching the line between rows), never over the bar or its size text, and sideways inside the measurement when it fits, just past the right tick when it does not, or just before the left tick when the measurement ends at the chart's right-hand edge, so no line, arrowhead or bar ever crosses it. When the gear's Row height is too small for a label under the bar (below 52 px with the default bar height), the label sits beside the bar at the bar's own height instead. (Fixed 2026-09-14: it used to sit at the line's height a fixed distance in from the left tick, so the right tick ran through it on short measurements and it covered the bar's text.)
• Over capacity — every open bar of a person who is over capacity before the target date takes a red ring, keeping its own colour, so overload is visible without turning the chart red. The person's name in the Assignee column turns red too.
• On the critical chain — a dark blue outline.
• Dependency arrows — from Jira's own blocks links. Every line and arrowhead is grey. An arrow that points backwards — the blocker sits in a sprint that starts after the sprint of the work it blocks has ended — is drawn dashed: that is work waiting on work that is scheduled after it, and it is the same conflict the Alerts tab reports.
• The allowance — a hatched tail on the row of the issue that finishes last, from its end to the forecast pin, labelled N days of allowance (see Where the numbers come from).

The table down the left

Twelve columns: Key, Summary, Assignee, Sprint, Points, Remaining Est, Original Est, Status, Type, Start Date, Due Date and Progress. In a time project the Points column is headed Size; Remaining Est and Original Est are shown in hrs. Under Shared capacity the Sprint column becomes Project. The Sprint column is dropped in a project with Sprint Mode off, because there is nothing to put in it. Key and Summary are always shown; any of the other ten can be switched off in the gear.

An epic's own row carries the epic's key (a link to it in Jira), its heading, Epic as its type, the size of the work still open inside it, and the epic's due date.

Every heading sorts. Clicking one sorts by it, clicking again reverses it, and a third click puts the order back to whatever the grouping gives. Sorting happens inside each band, never across bands.

The divider between the table and the chart is draggable, and the arrow on it hides the table to give the chart the full width, or shows it again. The two panes scroll together: the table follows the chart vertically, and the column headings follow it sideways.

Start Date means the date held in Jira — the same field the rest of the app calls Start Date — and editing that cell writes that field. Where Jira holds none, the cell shows the worked-out date instead, marked (worked out). Due Date likewise shows the issue's own due date, or a borrowed one marked with where it came from, for example (from its sprint).

View settings (the gear)

The gear at the end of the control row opens View settings. Everything in it changes how the chart is drawn and nothing in Jira, and it is kept with the project, along with the grouping, the scale, the zoom, the Work starts rule, Critical chain only, the sort and where the divider sits — leaving the tab and coming back finds the chart the way it was left.

• What the chart draws — Dependency arrows, Epic spans, Committed dates, Today, target and forecast, Column shading, Sizes on the bars, The table on the left, Column lines through the chart, How much is done inside each bar, and Work with no estimate. All start on.
• Gantt view options — sliders for Row height, Bar height, Height of the column headings, Width of the table on the left, Width of one day, Dependency arrow thickness and Dependency arrow head.
• What a person can do to a bar — Drag the divider to resize the table; Read only: nothing can be moved (your own choice not to move anything by accident; it never lets the tab write where it could not already); Drag a bar sideways to set its start; Drag its end to set its due date.
• Columns in the table — a box for each column, with All, Fewest, Draw everything and Put every view option back at the foot.

Grouping and folding

Group by sits in the heading of the table on the left, above the column names, because what it changes is that table's rows. It starts on Epic. The choices:

• Epic — one band per epic, its issues beneath; issues with no epic in a No epic band at the end.
• Person — one lane per person, carrying their work from every project on screen.
• Project — one band per project. Offered only while Shared capacity is on.
• Sprint — one band per sprint. Reads Period in a project with Sprint Mode off, where each issue is banded by the period it starts in.
• No grouping, by due date — every issue in one flat list, earliest due date first, an issue with no due date of its own being due at the end of the sprint it is in, one in no sprint taking its epic's date, and issues with none of the three sitting at the end.

Beside it is one arrow that folds every band or opens them all again. It points down when anything is open and right when everything is shut. Each band also has its own arrow.

Where the work starts

The chart needs to know the earliest an issue can begin. Most teams do not put start dates on issues, so Work starts in the control row offers three rules:

• As soon as possible — the default. Work begins today, pushed later by whatever blocks it and by whatever else is already queued for the person doing it.
• Not before the epic starts — an issue cannot begin before the start date on its epic. An epic with no start date, or one that has already passed, changes nothing.
• Just in time for the due date — offered in time projects only. The bar is placed so the work finishes on the issue's due date, starting back by as many working days as its hours need.

Whichever is chosen, the notice above the chart says which rule is in force, so when a date moves it is clear what moved it.

One thing is never a choice: a person's booked time off and the public holidays on their calendar push their work later under every rule. Whether somebody is at work is not a preference. A whole day booked off steps the work over that day, so a week of leave moves the finish a week later; half a day booked off does not shorten a bar, because the day is still a day at work, and its hours are still subtracted everywhere capacity is worked out.

Show baseline

A Show baseline dropdown sits in the control row beside Work starts, once the project has at least one baseline saved in the Dashboard's Baselines section (with none there is nothing to choose, and the row is as it was). It reads None, then every saved baseline, newest first, each with the date it was captured. Choosing one changes what the chart means rather than how it looks (added 2026-09-13, proposal 89):

• Under each bar, a thin grey bar at the dates that baseline held for that issue.
• At the grey bar's end, the number of working days the work has moved since, shown only where it moved; an issue finished since is measured on the day it was actually finished.
• Work the baseline never knew about is drawn with a dashed outline and reads added since the baseline in the key; work the baseline knew about that no longer exists is listed in the notice as removed since.
• The notice gains a line naming the baseline and when it was captured, how far the delivery forecast has moved since then in working days, which issues now hold the finish date, and how many issues moved, were added or were removed.
• The hover card gains a Baseline row: the dates that baseline held, how far the issue has moved, and who held it then if it has been reassigned.
• A change held on the chart and not yet written to Jira — a bar dragged, a date typed in a cell, a bar pulled longer — counts in the comparison exactly as the bar shows it, so the grey bar's figure and the blue bar above it always agree; Discard changes puts the comparison back with the chart.

The comparison is the same one the Dashboard's Baselines table shows in its Moved column — one function, so the two can never disagree. A baseline saved before 2026-09-13 has no per-issue record; choosing it puts one line in the notice: This baseline was saved before per-issue dates were kept. Capture a new baseline to compare. Nothing is guessed for it. The dropdown is not offered in Shared capacity, where the chart shows several projects at once; choosing None puts the chart back exactly as it was.

The critical chain

Critical chain only, a box in the control row, fades every bar that is not on the chain, along with every committed-date marker, days-late measurement and dependency arrow that belongs to faded work. There is no separate view to switch to — it is the same chart with everything else turned down.

The chain is the longest run through the plan, and two different things can hold a run together: work blocked by work, and one person doing several jobs one after another. The tab says which it is — beside the box while the box is ticked (showing the longest run through the plan — …), and in the notice above the chart whenever there is a chain. A run held together by blockers is shortened by breaking a dependency; a run that is one person's own queue is shortened by finding a second pair of hands, and the note names that person.

More than one project at once

The project selector is the app's own, at the right-hand end of the tab bar: Program view, then every registered project by key and name.

Shared capacity, the first button in the control row, puts every registered project on the chart at once. One press sets two controls — the project selector to Program view and Group by to Person — and the button then reads Back; pressing it puts both back as they were. It is greyed out until a second project is registered.

The part that matters is underneath the picture: the schedule is worked out once across every project on screen, never per project and then stacked. A person has one capacity and one queue, not one per project. That is the difference from the portfolio views in the other tools, which stack one chart per project — so a person booked solid on two projects looks comfortable on both.

• Group by Person gives one lane per person carrying their work from every project. This is where a person loaded across two projects becomes visible. Each issue's project is named in the table's Project column and in its hover card.
• Group by Project is offered while Shared capacity is on, one band per project.
• The three cards are the tab's own cards, worked out from the project data the app has loaded; they are not given the All Projects roll-up the What-If tab uses.
• The T pin, the shading past the target and the over-capacity check all use the one date on the Target Date card.
• Show baseline and Include backlog are not offered, and the Project column that replaces the Sprint column cannot be edited.

Hovering and clicking

Hovering a bar shows a card carrying the issue key and summary, its project (under Shared capacity), its assignee, its epic, its sprint, its size with the share done, the pace it was drawn at (the hours a week whoever holds it is down for, and what that is a day; on a points project where only points are typed for them, their points a sprint and what that is a day), its forecast start and finish, its committed date with the working days late where it runs past it, what it blocks, whether it is on the chain — yes or no — and a closing sentence, Starts when it does because:, giving the reason: it is done, a start date on the work itself, its sprint does not start until a date, another issue has to finish first, the person who has it is busy until then finishing another issue, or nothing is holding it back so it starts today. Where the date was typed rather than worked out the card says This date was set by hand. Double-click the bar to clear it.

Clicking an issue key — in the table, or on an epic's own row — opens that issue in Jira in a new tab, as the key on the Epics tab does. The bars themselves are for dragging, so clicking one does not open anything.

Editing on the chart

Bars can be dragged and resized, and cells in the table can be changed. Nothing is written to Jira as it is dragged.

• Drag a bar sideways — sets the issue's start date, and its due date moves with it so the length is unchanged.
• Drag either end — makes the bar longer or shorter, which changes the size of the work rather than its due date. The length of a bar is the work, so the estimate follows it at that person's own pace. Dragging the left end also moves the start date.
• Drag a bar into another person's lane — reassigns the issue to that person. Available when the chart is grouped by Person.
• Drag a bar onto another sprint band — moves the issue to that sprint. Available when the chart is grouped by Sprint, in a project that uses sprints.
• Double-click a bar — takes both its typed dates off, handing the work back to the schedule.
• Change a value in the table — Assignee (only people the app can name to Jira), Points (Size in a time project), Sprint (a list of the open sprints and No sprint; not under Shared capacity), Start Date and Due Date can be edited in place. The × beside a start or due date takes it off. Status is shown but not edited here: changing a status is a transition in Jira rather than a field, and this tab does not make one.

A changed cell or bar is marked as changed, the chart is worked out again from the change straight away, and the count of waiting changes appears on the Update Jira button. Discard changes puts everything back.

Nothing reaches Jira until Update Jira is pressed. The confirmation, headed Update Jira, lists every change, issue by issue and field by field, under the line N changes will be written. Nothing has been written yet., with Cancel and Write N to Jira. A change Jira refuses stays on the chart and is reported as refused, with Jira's own reason, rather than being reported as saved.

Fill in due dates (added 2026-09-10) stages a due date for every issue shown on the chart that has none of its own in Jira, using the date the chart is already using for it — the end of the sprint it is in, or its epic's date when it is in no sprint. Issues inside a folded band are not included. Most teams put a date on an epic and nothing on the issues inside it, so every screen borrows that date while Jira itself still holds nothing, and the board, the backlog and every other tool show no date at all. The button's count is how many issues it would give a date to; an issue that already carries a date somebody typed is never touched, and neither is one that has just been given one on this chart. Nothing is written when the button is pressed: the dates join the waiting changes and go through Update Jira like every other change, so the list is seen first. After they are written, the report offers Undo N due dates, which puts each of those dates back to nothing — through the same list-then-write path, so nothing is undone unseen either.

A start date set by dragging a bar or typing in the Start Date cell is the earliest the work may begin, not a fixed date. The bar starts on it only when nothing holds the work back further. When the sprint the work is in starts later, when the Work starts rule gives a later date, when work that blocks it finishes later, or when the person doing it is still busy with other work, the bar starts at the latest of those instead. The bar is drawn striped only while the typed date is what places the work, and then it starts on that date exactly as typed. When something else pushes the work later, or the typed date has already passed so the work starts today, the bar is drawn plain, and the note above the chart counts it separately, as a start date that is not what places the work.

Editing works in the app inside Jira, unless Read-only Mode is on, and in the demo, where changes are kept in the browser only. The connected web app is forced read-only, so there the chart draws, the bars do not move, and Fill in due dates, Discard changes and Update Jira are not shown. Anyone can also tick Read only: nothing can be moved in the gear.

When there is nothing to draw

• Nothing left to schedule — Every issue in the open sprints is done, so there is nothing to place on a timeline.
• Nothing can be timed yet — issues are waiting, but the people holding them have no capacity set on the Team & Capacity tab (no hours a week on a time project, no capacity in points typed on a points project); the message names them and says the chart draws itself once their hours are set.

The three cards still show above either message.

What the first version deliberately does not do

• No dragging as a what-if. A bar that is moved sets a date, and that date is written to Jira on the button. To test a change without writing anything, use the What-If tab.
• No writing without the button. Nothing on this tab reaches Jira until Update Jira is pressed and the list of changes is confirmed.
• No new numbers. Every date, share, verdict and label on the tab is one the app already shows elsewhere.

Where the numbers come from

The bars come from the same scheduler that draws the Critical Chain section on the Projects tab: it forward-schedules every open issue from today, respecting dependencies, each person's real capacity, and any date already set on an issue.

The target date, the forecast date and the likely range come from the Delivery Forecast and Target Date cards above the chart, unchanged.

Those two are different calculations answering different questions, and where they disagree the chart says so rather than hiding it. When the forecast date is later than the last issue's finish, the row of the issue that finishes last carries on to the forecast pin as a lighter, hatched tail labelled N days of allowance; hovering it says The forecast carries N working days of allowance past the last issue, and the notice explains that the gap is the allowance for how much velocity has varied. When the last issue finishes after the forecast date instead, the notice says so and why: the bars queue each person's work one issue at a time, while the card simulates a sprint's whole capacity, so where they disagree the bars are the stricter answer.