Once you have created your portfolio, you can see all the details on this page.

Browse through all the features from this portfolio and see which teams are involved, which features are being actively worked on, and what the progress as well as the projected completion is.

• General Portfolio Information and Actions
  • Refresh Features
  • Settings
• Forecasts
  • Features
    • Hide Completed Features
    • Feature Order
    • Feature Name
    • Parent
    • Feature Progress
    • Forecasts
    • Forecasted Start
  • Feature WIP
• Deliveries
  • Add a Delivery
    • Manual Delivery Creation
    • Rule-Based Delivery Creation
      • Creating a Rule-Based Delivery
      • Validating Rules
      • Automatic Updates
    • Following a Jira Release
      • Creating one
      • What Jira maintains from then on
      • When the Release goes away
  • Publishing a forecast back to Jira
    • If Jira will not take the write
  • After it’s added
  • Archiving a Delivery
  • Delivery Metrics over Time
    • Burnup
    • Predictability
      • Honest charts when the target moves
    • Fever Chart
    • Features over Time
  • Delivery Timeline
    • Choosing a confidence level
    • The target date
    • What the bars can tell you
    • Status: how each bar stands against the target date
    • Teams: who works each bar
    • Warnings: what is worth checking
    • Dependencies between bars
    • Features already under way
    • Features that cannot be drawn
    • Why a feature nobody has started can show as starting today
    • Bars that touch
• Metrics
• Reports

You can directly go to the portfolio detail page if you bookmark the specific URL. Even if the portfolio name changes, the URL will stay the same.

General Portfolio Information and Actions

On top you can see general portfolio information, which includes the name of the portfolio and it was last updated.

Refresh Features

While portfolios are continuously updated, you can trigger a refresh manually by clicking the refresh icon in the header. This will update the Features and all associated forecasts.

A manual refresh can be useful if you just made significant changes (for example added new features to the portfolios) and do not want to wait for the periodic update to kick in.

After you trigger the manual refresh, the refresh icon will be disabled while the portfolio is updated. Depending on the load of the server and other operations which might be in progress, it can take a while. While every context and portfolio is different, an update should normally not take longer than two minutes.

Settings

Portfolio settings are available in the Settings tab on the Portfolio page. They contain the same settings as the Portfolio Creation.

For frequently used adjustments there is a Quick Settings bar in the header that allows you to change common values (SLE, System WIP, Portfolio Feature WIP) without leaving the page.

Forecasts

Features

For every portfolio, all the features are listed with additional details.

Hide Completed Features

If you have many Features that are already completed, you may not want to show all of them. In such a scenario, you can hide the completed features. The setting is stored for this specific portfolio, so next time you won’t have to toggle it again.

Feature Order

Features are ordered based on the order in your Work Tracking System. To change it, adjust your Work Tracking System and Refresh the Features.

The order is crucial, as Lighthouse forecasts based on the Feature WIP of each Team from highest to lowest ordered Feature. Note that the order is instance-wide: the Features of every Portfolio compete for the same Teams, so this list shows one slice of a longer sequence. The Features page shows the whole of it.

If you would rather Lighthouse owned the order than your Work Tracking System, turn on Feature Order under System Settings. Each row then offers Move to Top, Move Up, Move Down and Move to Bottom — see Moving a Feature. Owning the order is a Premium capability.

Feature Name

The name of the feature. This is also a clickable link, that points to this specific item in your work tracking system.

Parent

The item each Feature hangs under in your work tracking system — for example an Initiative or Objective if you use OKRs or some kind of quarterly planning. The name links to the item in your work tracking system; No Parent means the Feature has none. To take the parent from a different field, set a Parent Override Field.

Three further columns say something about every row:

• Warnings carries one icon per Feature — a green check when there is nothing to say, an amber triangle when there is. Hover it to read every reason at once: a Feature marked done that still has open Work Items, one using the Default Feature Size because it isn’t broken down yet, or a dependency Lighthouse can’t take into account. See Warnings.
• Active Work shows whether any involved team currently has child items of this Feature in a Doing State, and names the teams.
• Dependencies lists the other Features this one is waiting on, read from your work tracking system. See Dependencies.

In general you should be working on the top-most features, while the ones further down the order may not be broken down yet. If features on top are not yet broken down, this may be a signal that you should invest some time in breaking them down.
If features towards the bottom are in progress, you may focus on the wrong thing.

Use Lighthouse to make such things transparent and trigger a discussion around what to focus on!

Feature Progress

In the progress column, you can see how many items are done and how many are pending for this feature. This is split by the total amount for the feature and a more detailed view for every involved team.

If a team is working solo on a feature, both bars will show the same numbers.

Forecasts

For each Feature you will see the forecasted completion date. You’ll get four different probabilities, from Certain to Risky. Naturally, the riskier the forecast, the earlier the projected completion.

A probability that too few simulated runs reach within five years reads More than 5 years instead of a date. See When a Forecast Reaches Beyond Five Years.

The completion dates of each feature will take into account all teams that are involved. If a single item is planned to be done by one team, but this is far down their priority, this will mean that the feature completion will be moving backwards. Lighthouse cares about delivering complete features. You may be able to use such scenarios to kick off a discussion about how work or teams are sliced (as less dependencies mean more effective delivery).

Forecasted Start

Beside the completion dates, the Forecasted Start column answers the other half of the question: the day work on a feature is forecast to begin. It reads exactly like the completion column — the same four probabilities, on the same scale — because it comes from the same simulation.

A start date far out is Lighthouse telling you about the queue rather than about the feature. Nothing starts until the teams that will work it are free of everything ordered above it, so the column is the quickest way to see what a long order is actually costing the things at the bottom of it.

A feature that has already started shows the day it actually started, at all four probabilities. A date that has happened is a fact, and no probability moves it.

A feature no involved team can be forecast for says so here, exactly as the completion column does.

The column appears wherever features are listed — this page, the Team page, the Features page and inside a delivery — and it needs no licence. It can also be written back into your work tracking system; see Data Sync Mappings.

Feature WIP

Lighthouse forecasts are based on the Order and the Feature WIP of each involved team. You can change this via the settings of a team or by using the Quick Settings bar in the portfolio header. Changing Feature WIP will automatically reforecast the completion dates.

Adjusting the Feature WIP for The A-Team from 1 to 3 caused the probabilities to change. In general, increasing the Feature WIP will mean that lower ordered features will be completed sooner, while higher ordered features take longer to finish.
A Feature WIP of 1 means, the team will only work on the top most feature, and move to the next one only when this is all done. The single focus of this team is on one feature.
On the other side of the extreme, if we have a Feature WIP of 10, we will split our efforts across ten things, dilluting any kind of focus, and doing many things in parallel.

You should strive for a Feature WIP that is as low as possible, ideally 1 or 2. However, if your reality looks different, it makes more sense to set Lighthouse up accordingly, as otherwise the forecasts will be off.
You may use Lighthouse to make it transparent what a change in Feature WIP can mean in terms of Feature delivery, which could be a good conversation starter to make a change.

If a team is configured to Automatically Adjust Feature WIP, you can still change the settings manually. However, they will be overridden the next time the Team Data will be updated.

Deliveries

Deliveries are named milestone dates for a portfolio that group a set of Features intended to be released together. They help you communicate target dates, track which features belong to a delivery, and see delivery-level progress alongside feature forecasts.

Add a Delivery

To add a delivery to a portfolio, open the portfolio and click the Add Delivery button. This opens the delivery form where you define the delivery name, target date and how features should be selected.

Lighthouse offers three ways to select features for a delivery:

• Manual Selection: Manually pick specific features to include in the delivery. Features remain fixed unless you manually update them.
• Rule-Based Selection: Define rules that automatically match features based on criteria from your work tracking system (Premium feature only).
• Follow a Jira Release: Point the delivery at a Release that already exists in Jira. Its name, its date and the work tagged against it all come from Jira from then on (Premium feature only).

Manual Delivery Creation

• Click Add Delivery to open the form.
• Ensure Manual mode is selected.
• Fill the required fields: Name (a clear title for the delivery), Date (target delivery date), and Features (select one or more features to include).
• Click Save to create the delivery. The new delivery will appear in the Deliveries list and can be edited or removed later.

You can select multiple features for a single delivery — Lighthouse will show delivery-level progress and the forecasted completion of each included feature.

Rule-Based Delivery Creation

Rule-based deliveries provide a flexible, automated approach to feature selection by defining expressions that match features from your work tracking system. This creates a single source of truth — features are automatically included or excluded based on data already present in your work tracking system (such as tags, fixVersion in Jira, Area Paths in Azure DevOps, or custom fields).

Rule-based deliveries are a Premium feature and require a Premium license.

Creating a Rule-Based Delivery

• Click Add Delivery to open the form.
• Switch to Rule-Based mode by clicking the Rule-Based tab.
• Fill in Name and Date as usual.
• Click Add Rule to create your first rule condition.
• For each rule, select:
  • Field: Choose from available fields like Type, State, Tags, Name, ReferenceId, ParentReferenceId, or any custom fields defined in your work tracking system connection.
  • Operator: Choose how to match the field value:
    • equals: Exact match
    • notequals: Does not match
    • contains: Partial match (useful for tags or text fields)
  • Value: Enter the value to match against (e.g., “Release-2.0” for tags, “Epic” for type).

You can add multiple rules (up to 20). All rules must be satisfied for a feature to be included (rules are combined with AND logic).

Validating Rules

Before saving, click Validate Rules to preview which features match your expression. The matched features will be displayed below the rule builder. At least one feature must match for the rules to be valid.

Use rule-based deliveries when your work tracking system already organizes features by delivery using fields like:

• Jira: fixVersion, labels, or custom fields
• Azure DevOps: Area Paths, tags, or iteration paths
• Custom Fields: Any additional fields you’ve configured in Lighthouse

This approach maintains your work tracking system as the single source of truth and automatically keeps deliveries up-to-date.

Automatic Updates

Rule-based deliveries are automatically updated every time the portfolio is refreshed (either manually or during periodic updates). The rules are re-evaluated against current portfolio features:

• New features matching the rules are automatically added
• Features no longer matching the rules are automatically removed

This ensures your delivery always reflects the current state of your work tracking system without manual maintenance.

Each delivery uses one selection mode at a time — Manual, Rule-Based, or following a Jira Release. You cannot mix them for a single delivery, though you can switch between modes when editing one.

Following a Jira Release

If your teams already plan against Releases in Jira, the date you would type into Lighthouse is a date somebody has already entered. Pointing a delivery at that Release stops you keeping the same number in two places.

Following a Jira Release is a Premium feature and requires a Premium license. It is offered only on portfolios whose connection is a Jira one, and works on Jira Cloud and on Jira Server / Data Center from version 8.

Creating one

• Click Add Delivery to open the form.
• Switch to the Jira Release tab.
• Pick a Release from the list. Every Release the credential can see is offered, across every project — a customer’s releases often live in a project of their own, away from the work itself.
• Lighthouse shows the date the Release would set and the features that would come along with it, so you can see what you are about to get before you save it.
• Click Save.

The name field and the date field are filled in for you and cannot be typed into. That is the point: from here on Jira owns them.

While the form is still finding out what the portfolio’s connection offers, whether your license covers Premium features, or which Releases there are, it says it is loading rather than guessing: a busy Loading… tab sits in the tab row, and the Jira Release tab reads Getting the Jira Releases…. If something cannot be loaded, the form says so in place. Close the form and open it again to retry.

A Release that has no date cannot be followed — there is nothing for the delivery to take. Give it a date in Jira and it becomes selectable.

What Jira maintains from then on

Every portfolio refresh asks Jira what the Release says now, and applies it:

• The name and the date, including a date that moves later or earlier.
• The features, from the work tagged with that Release — narrowed to the ones this portfolio tracks.

A date in the past is applied like any other. A Release that shipped last quarter shows its real date, marked overdue, rather than being refused for not being in the future.

Because Jira maintains all three, the delivery refuses to let you rename it, move its date, or change its features by hand. To take it back, use Stop following on the link icon beside the delivery name — it keeps the name, the date and the features it has at that moment, and they become yours to edit again.

When the Release goes away

If the Release is deleted, loses its date, or the connection stops offering Releases at all, the delivery says so on screen and keeps everything the Release last gave it, along with the day it last heard from it. Nothing unbinds on its own and nothing is deleted — the numbers are still worth reading, and what has changed is that nobody is maintaining them any more.

A Jira that is briefly unreachable is not treated this way. A failed request says nothing about whether the Release still exists, so the delivery simply keeps its values and the next refresh asks again.

Publishing a forecast back to Jira

A delivery that follows a Jira Release can also send its forecast the other way, so people who plan in Jira and never open Lighthouse can see it on the Release they already read.

Switch Publish forecast to the Jira Release on in the delivery form, under the Release picker. It is off unless you ask for it, and it is set per delivery — a portfolio often holds some Releases that are shared with a customer and some that are not.

Lighthouse then writes a block into the Release’s description, and keeps it up to date on every refresh:

🔮 Lighthouse forecast - updated 2026-08-22
70%: 2026-09-15
85%: 2026-09-29
95%: 2026-10-13
Target 2026-10-01: 88% likely
🔮

• Anything else in the description is left exactly as it is, and re-writing replaces the block rather than adding a second one.
• The three percentiles are the same ones Lighthouse shows on its own screen, so the two can never disagree. One that Lighthouse shows as More than 5 years is written the same way, for example 85%: More than 5 years, never as a date.
• The release date in Jira is never touched. Lighthouse writes its forecast into the description and leaves the target date to you — otherwise the forecast would become the target it is measured against.

Editing a Release description does not notify anyone, so this does not add to whatever notification volume your Jira already produces.

If Jira will not take the write

Editing a Release needs project administrator rights on the project that Release belongs to. Most credentials have them; some do not, and it is per project rather than per site — the same login can be allowed on one project and refused on the next.

When a write is refused, the delivery says so, quotes Jira’s own words, and names the day it last tried. Nothing is disabled: the next refresh tries again, and the report disappears once a write goes through. Reading the Release carries on working throughout — reading and writing are separate permissions, so a refused write never stops the date syncing.

After it’s added

After creating a delivery it appears in the Deliveries view with its name, target date and the list of included features.

The delivery row shows the delivery name and date, along with a visual indicator showing how its features were chosen:

• Manual deliveries show a touch icon, indicating features are fixed
• Rule-based deliveries show an automatic mode icon, indicating features update automatically based on rules
• Deliveries following a Jira Release show a link icon. Clicking it is how you stop following the Release

The row also includes an expand control to reveal included features and their statuses, and action buttons to archive, edit or delete the delivery. Expanding a delivery displays each feature and its forecasted completion so you can assess delivery risk and progress at a glance.

Use deliveries to communicate release milestones and to group related features — this makes it easier to discuss release risk and progress with stakeholders.

Archiving a Delivery

Once a delivery has shipped — or been called off — you can archive it. It leaves the active list, and the numbers it was showing at that moment are written down and kept: the likelihood, the forecast dates, and every feature that was in it.

Archiving is a premium feature. Bringing a delivery back is not — if your licence lapses you can still un-archive whatever you archived.

Archiving asks for confirmation first. If you retire deliveries often, tick Don’t ask me again and later archives skip the dialog. That choice is remembered in your browser, so you will see the dialog once on a new machine.

Archived deliveries collect in an Archived section below the active ones, collapsed until you open it. Each shows the day it was archived, the numbers as they stood then, and which features were in it.

The point of archiving is that the record stops moving. Refresh the portfolio, let features be renamed, re-estimated or removed entirely, and an archived delivery still reads exactly as it did on the day it closed. That is what makes it usable as evidence in a review months later.

Because those numbers are fixed, an archived delivery shows less than a live one: which features were in it, and nothing about how far along they are today. Anything else would invite a comparison the record cannot support. Export still gives you the full detail — the same file a live delivery produces, built from the stored numbers.

An archived delivery also stops being maintained: it no longer records daily metrics, and a rule-based delivery stops re-matching features. Its Metrics tab still shows the history up to the day it closed. Notes stay readable but can no longer be added, edited or withdrawn.

Un-archive returns it to the active list, and live recomputation and daily recording resume from there.

Archiving is not a substitute for keeping a copy elsewhere. Deleting an archived delivery still deletes it permanently, and takes the written-down numbers and its metric history with it.

Delivery Metrics over Time

Expand a delivery and open its Metrics tab to see how the delivery has tracked over time. Where the feature forecasts answer “where do we stand today?”, these charts answer “how has the picture changed, and is it getting better or worse?”. They build forward from the moment the delivery is created — each daily snapshot adds a point — so the history grows richer the longer a delivery is live.

Burnup

The burnup chart plots total scope against completed work over time.

• The Backlog line is the total number of items in the delivery; it rises when scope is added.
• The Done area is how much has been completed.
• A dashed Estimated line appears when the delivery still contains features that have not been broken down, so you can see how much of the scope is a placeholder estimate rather than counted items.

The gap between Backlog and Done is the remaining work — watching the two lines converge (or diverge) tells you whether the delivery is closing in on completion or losing ground to scope growth.

Predictability

The predictability chart tracks the forecast itself over time and offers two views via the toggle in its header.

How Likely? shows the probability of hitting the target date on each day, plotted against coloured confidence bands (Risky → Certain).

When? shows the forecasted completion dates (50th, 70th, 85th, and 95th percentiles) over time against the delivery’s target date. A day on which a percentile read More than 5 years has no date to plot, so that point is left out.

Honest charts when the target moves

If you change a delivery’s target date, the charts do not silently rewrite history. The target is recorded as it was on each snapshot, so the target line steps on the day it changed, and a marker highlights the change on the How Likely? view. This keeps the forecast honest: a sudden jump in likelihood is clearly attributable to a moved target rather than to real progress.

Fever Chart

The fever chart places each feature in the delivery on a schedule-versus-confidence plot, coloured green / amber / red by risk, and animates the trail of how that position evolved.

Use the Run control to replay the trail over time. A feature drifting up into the red zone is consuming its buffer faster than it is making progress — an early-warning signal long before the target date arrives.

Features over Time

The burnup tells you the delivery grew. This chart tells you which feature grew, and when.

• Each day is one stacked bar, with a band per feature sized by the number of items it holds. A band that suddenly gets taller is scope discovered inside that feature; a band that ends is a feature that left the delivery.
• The orange Count line, on its own right-hand scale, is how many features were in the delivery that day. It answers a different question from the bars: three features of ten items and ten features of three items both total thirty, but they are not the same delivery to run.
• A hatched band means the feature’s size is still the portfolio’s default estimate rather than counted items. Watching a band switch from hatched to solid is watching a feature actually get broken down.

Features keep the same colour here as on the fever chart above, and hold their position in the stack from day to day, so following one feature across the window is a matter of following one colour.

Click Legend to open it, then click features to show only those bars — useful once a delivery carries more than a handful. The Count line is a delivery-level fact and is never filtered.

This chart uses whatever you call features in Settings → Terminology, so it may be titled Epics over Time, Initiatives over Time, or something else on your instance.

The feature count is drawn from the same daily snapshots the other charts use, so it goes back as far as this delivery’s history. Feature sizes and the estimated/counted distinction were added later and are recorded from that point forward, so bars begin on the first day Lighthouse recorded them — earlier days show the count line alone. Features with no items at all are not counted.

These charts accrue from the day a delivery is created. A newly added delivery shows an empty state until the first snapshots are recorded — give it a day or two of background updates to populate.

Delivery Timeline

Expand a delivery and open its Timeline tab to see the delivery as a plan: one bar per feature, running from the day work on it is forecast to begin to the day it is forecast to finish.

This is the view that answers “what order will these get worked, and when does each one actually start?”. The Features table answers it a row at a time; the timeline answers it at a glance, and shows you the queue — the features that cannot start yet because the teams are busy with the ones above them.

Features appear in board order, top to bottom. That is not a display choice: it is the order Lighthouse’s simulation itself pulls them in, so the picture and the forecast behind it agree.

The Timeline is a premium feature. The forecasts it draws are not — the start and completion dates stay in the Features table on every licence.

Choosing a confidence level

The 70% / 85% / 95% buttons above the chart set the confidence level for the whole timeline. Moving between them slides both ends of every bar together, so each bar is always one consistent scenario rather than an optimistic start welded to a pessimistic finish.

Switching from 70% to 95% and watching whether the last bar still lands before your target date is the quickest read on how much slack the delivery really has.

The target date

Where a delivery has a target date, that day is shaded on the axis. The shading uses the same date shown in the delivery’s heading.

What the bars can tell you

Next to the probability buttons is a second group of buttons, Show, offering Nothing, your word for teams, Status and Warnings. One at a time, deliberately: each of them wants the bar’s own colour, and a chart answering two questions at once would have to say one of them in something smaller and dimmer.

Status is what you get if you have never chosen. Of the four it is the only answer you cannot get anywhere else — which teams work a feature, and what is worth checking about it, are both on the Features table above; whether a bar crosses the target date is not.

A button is offered only where this delivery can answer it. A delivery with no target date and nothing finished has nothing to say about status, so Status is absent rather than offered and inert. Where only one of the four applies, the group goes away entirely — a lone button reading Nothing is a statement dressed up as a control.

Your choice is remembered, and it is one choice for the page rather than one per delivery. Open another delivery that cannot honour it — you asked for teams, and every feature there has only one — and that delivery shows nothing extra rather than something you did not ask for. Your choice is left untouched, so the delivery that can honour it still does.

Status: how each bar stands against the target date

Each bar takes one colour, and the key above the chart names all three every time, whichever ones this delivery happens to be wearing:

• Finished — the work stopped. That bar already ends on the day it stopped rather than on a forecast, so whether it beat the target is not a prediction anyone is making, and Lighthouse does not grade it either way.
• Not even started by the target date — the sharpest case, and it outranks merely finishing late. Every bar that starts after the date also ends after it, so without the ranking you would never see this one; and it is a different conversation, about what the delivery contains rather than about how fast anyone is going.
• Finishes after the target date — everything else that crosses the line.

A bar that is on track keeps the ordinary colour and says nothing. A colour worn by nearly every bar tells you nothing about any of them.

The comparison is day against day: a bar ending on the target date is on track, not late by a few hours.

A delivery with no target date can still say what is finished. That is the one verdict it can reach on its own.

Teams: who works each bar

This splits a feature worked by several teams into a row per team, drawn beneath the feature’s own bar, each row carrying that team’s own dates, colour and name. The feature’s bar itself never moves: it still spans the whole of the work, from the first day any team starts to the last day any team finishes.

A feature only one team works keeps its single bar and wears that team’s colour and name, so the view answers which team on every row rather than only on the split ones. A key above the chart names every team on the chart, and a team keeps the same colour as you move the probability buttons.

A team whose part cannot be forecast gets no row of its own — there are no dates to draw one from — and is named on the feature’s bar instead, with the reason. The split never shows fewer teams than the feature has.

Every row is a forecast, including under a bar that begins on a day work really started. Lighthouse records the day the feature started, not the day each team joined it.

Warnings: what is worth checking

This puts the same sentences the Warnings column carries onto the bars themselves, so a feature cannot read as clean on the chart and flagged in the table. A bar with something to say carries a symbol — an amber triangle where something is wrong, an information mark where it is merely worth knowing — and hovering it reads out every reason at once.

It also carries the one thing only this chart knows: what a feature is waiting on where no line was drawn for the wait.

Dependencies between bars

Where one feature in the delivery waits on another and the forecast took that wait into account, a line joins the two bars. That is all a line means, and it means nothing else: the reason this bar sits where it does.

Every other wait is said in words on the bar, under Show → Warnings, rather than drawn — a line would claim something that is not true. That covers a feature waited on that is not on this timeline, one that is here but has no bar to join to, and a wait Lighthouse could not take into account at all: the two are in no portfolio they share, they are waiting on each other, nothing has been measured to forecast the other from, or this instance has no premium licence. Those last ones also appear in the Warnings column, in the same words.

Where a portfolio has set its dependencies aside, that is said once above the chart rather than on every bar.

A delivery whose features wait on each other more than about forty times draws no lines at all and says every wait in words instead. Past that many, lines are a thicket, and a thicket tells you less than none would.

Features already under way

A feature that has already started begins its bar on the day it actually started, not on a forecast. A date that has happened is a fact, and no confidence level changes it — only the far end of the bar moves when you change the percentile.

Features that cannot be drawn

Some features cannot be placed on a timeline: no team has enough history to forecast them, the delivery has no forecast for one end of the bar yet, or the chosen confidence level lies more than five years out (Ends more than 5 years out at 85%). Those are listed beneath the chart with the reason, never silently left out.

This matters more than it sounds. A feature that vanishes from a plan is worse than one shown as unknown — you would be reading a picture with a hole in it and no way to tell.

Why a feature nobody has started can show as starting today

This is the one thing on the timeline that looks wrong and is not.

Lighthouse forecasts the top few features on each board — as many as the team’s feature WIP allows — as the ones being worked right now. It reads the board’s order, not what is physically in progress. So if a feature sits high in the order while the team is actually working on something further down, the timeline draws the high one as starting immediately.

That is the timeline reporting your board, not misreading it. The forecast is telling you the order you have published does not match the order you are working. Reordering the board so it reflects reality changes the picture — and is the thing worth doing regardless, because everything downstream of the board reads that order too.

Bars that touch

Where one team works several features in sequence, you will see each bar begin on the same day the one above it ends, with no gap. That is correct. A team that finishes a feature part-way through a day pulls the next one the same day, so the handover is not a day long. A gap appears only where a different team has to pick the work up.

This tab uses whatever you call features in Settings → Terminology, so its bars may be titled with your own word for them throughout.

Metrics

Similar to the Team Details, the Portfolio contains metrics. The visuals are mostly the same as for the teams, the difference is that they are applied at feature level on the Portfolio. Check the Metrics Page for more details.

Reports

The Reports tab, between Metrics and Settings, keeps reports on this portfolio’s flow, such as a Then & Now report that shows whether flow changed since a given day. A Portfolio offers Then lengths of 90 or 180 days. See Reports for creating, editing and deleting them.