Projects Tab — Feature Guide

What it's for

The Projects tab is the programme view: every project the team is running side-by-side, plus the team allocation matrix that splits people across them, the cross-project dependency declarations that propagate slips between them, and the cross-project Critical Chain that finds the longest constrained path across the portfolio.

Four things live in one tab: register a new project, edit per-project settings, see a read-only portfolio dashboard with per-project health, and declare and watch cross-project blocking dependencies. The portfolio table is a monitoring view — it reports each project's forecast, slack, utilisation, and alerts and does not edit them inline. To model "what if" changes across the portfolio (adding people, scope growth, a slowdown), use the What-If tab's All Projects view, where sliders and a Monte Carlo simulation update the whole-program forecast and odds.

The audience is programme managers, portfolio leads, and engineering directors. A single project's view is on the Dashboard; this is where multiple projects meet.

In the web app at projectcommander.app/app, demo mode runs this tab on sample data (a project added there cannot load real work, and everything resets on reload), while Connect Your Own Jira registers real projects read-only, saved in that browser only. Team-shared registrations require the app installed in your Jira site from the Atlassian Marketplace.

Programme model

A programme is a set of related projects plus a shared team and the allocations between them. Each programme contains:

• Projects — registered with a Jira board ID and a JQL filter that defines membership.
• Team members — pool of people with base capacity (hours per week, points per sprint) drawn from the Team & Capacity tab.
• Allocations — per (member × project) entries stored as a percent of capacity, with hours and points kept as independent percents (a member can be 50% on hours and 60% on points for the same project, intentionally). The percent is the source of truth and survives capacity changes without rebalancing; the matching absolute "= X" is recomputed from it and labelled with its period (pts/sprint for points, h/wk for hours).
• Dependencies — declarative project A blocks project B statements.

Toolbar / header

The tab's table sits inside a folding section headed Projects, carrying the count (9 projects). Its controls run along one row:

• + Add Project — opens the project registration form.
• Select all / Deselect all — tick or untick every project's Active checkbox (see below) in one click. Shown only when at least one project is registered.
• The three health filter buttons (see Filtering by health below).
• A note at the end of the row saying how the table is currently ordered: Registration order — click a column heading to sort, or Sorted by <column> — click a column heading to re-sort once a column has been picked.

Add Project form

The form is key-first: type the Project Key and leave the field, and the app checks the key against your Jira site and fills in what follows from it — the project's real name, the standard "everything in this project" JQL filter, and the project's board. A key Jira doesn't recognize is flagged immediately next to the field. When the project has exactly one board it is selected silently (a note names it); with several boards the Board ID field becomes a short named picker; with none (or when the lookup is unavailable) the field stays manual. Auto-fill never overwrites anything already typed.

Required fields:

• Project Key — short uppercase id (e.g., AUTH); checked against Jira on leaving the field.
• Board ID — Jira board id; the engine fetches sprints and issues from this board. Found automatically from the key for most projects.
• JQL Filter — Jira-Query-Language filter selecting the issues that belong to the project; pre-filled from the key, editable for narrower slices.

Optional settings:

• Name — human-readable (defaults to the key).
• Target Date — acts as the project's fixed target when its target method is manual; the table's Target column always shows the computed target (see below).
• Estimation Mode — Story Points or Time. When Time is chosen, a Time Unit picker appears for Hours or Days (1 day = 8 hours); the choice is saved per project and every screen shows that project's time estimates and capacity in the chosen unit.
• Story Points Field — shown only in Story Points mode. Picks which Jira custom field this project's story points are read from (and written to, for inline edits). Jira sites store points in different fields — team-managed projects use Story point estimate (the default), company-managed ones use a separate Story Points field — and reading the wrong one makes every issue look unestimated. The dropdown lists the site's story-points-like fields with how many issues hold values in each, plus a Custom field number… entry; on Add, the evidenced field is pre-selected automatically when the default field is empty and exactly one other holds values. Full behavior, including the wrong-field notice on the Dashboard and Alerts tab, is described in the Settings Reference.
• Remaining Work — appears only when Estimation Mode is Time. Picks the ONE way unfinished work is counted everywhere for this project — every card, chart, demand figure, the weekly digest, and the delivery forecast engine alike: Committed size (full until Done) (the default — a task counts at its full estimated size until it is Done, and logged time never shrinks it) or Live estimate (after logged time) (a task counts at its Jira remaining estimate, which shrinks as work is logged). In Story Points mode the two are identical, so the control is hidden. Whichever basis is chosen, a screen's Burned % and Remaining % always sum to 100.
• Sprint Mode — on by default; when off, the project is treated as a continuous backlog.
• Sprint Capacity — the capacity of every sprint that has not been given a number of its own, in BOTH kinds of project: story points a sprint, or hours or days a sprint. The field label follows the project's estimation unit. Changing that unit changes the number with it — hours to days divides by eight, days to hours multiplies by eight, and a line under the field states what it became. Switching between story points and time clears the field instead, because the two cannot be converted into one another.
• Hours per story point — appears only when Estimation Mode is Time, default 4. How many hours one story point is worth, for issues estimated in points on a project estimated in time. Every screen that has to express point-estimated work in time reads it: the Can We Deliver row on the Dashboard, the Demand vs Capacity chart on the Scope tab, the Epics budget, and the Critical Chain demand model with the schedule behind it.
• Sprint Length — 1 / 2 / 3 / 4 weeks.
• Velocity Lookback — how many recent sprints are averaged for rolling velocity: any number from 1 to 10, the same shared value the Delivery forecast card's gear ("Use last N sprints") edits on the Dashboard, Scope and What-If tabs.

Add Project persists the new entry into the programme store and triggers a fetch.

Edit / Delete

Each project row has Edit and Delete buttons. Edit opens the same form as Add, pre-filled with the project's saved settings; the user can change any of them, and only the project key is required — so settings can be edited even when board ID or JQL are missing. This is also where an existing project's Story Points Field is corrected: the wrong-field notice on the Dashboard and Alerts tab points here, and after saving a different field the project's data refetches and every screen re-reads points from the newly chosen field. Editing never changes the stored field on its own — the automatic pre-selection from detection applies only when adding a new project. Delete opens a confirm dialog; on confirm, the project is removed together with its allocations, its cross-project dependencies, and its board's saved team. People who belong to no other project go with it (2026-09-02): anyone whose every share was of this project, or who has no share of any project, is removed from the team, and the dialog names them before you confirm; a person with a share of another project stays. When the deleted project was the one being shown and one project remains, every tab switches to the remaining project at once — its board, filter and people — with no reload. Choosing a project in the selector at the top right does the same (2026-09-03): the app's stored board, filter and capacity settings become that project's, so the Dashboard, Sprints, Team & Capacity and the rest all read its board; Program view leaves the stored board where it was. On a reload the selector starts on the project whose board is stored.

Active checkbox — include or exclude a project app-wide

The leftmost column of the portfolio table is Active: a checkbox per project, ticked by default (including every project registered before the checkbox existed). It decides whether the project is included anywhere in the app.

• Ticked (active) — the project appears everywhere it does today: the project dropdown in the top bar, the Program view union, the Dashboard / Scope / What-If program views, the Actions and Risks project pickers, the Team Allocation Matrix columns, the allocation popover on Team & Capacity, the dependency dropdowns on this tab, and every rollup and forecast.
• Unticked (inactive) — the project vanishes from all of those places at once and its Jira board is not fetched at all. Nothing is deleted: its settings, allocations, and declared dependencies are kept and return when it is re-ticked.
• On this tab the inactive project's row stays visible — greyed, with an Inactive tag next to its name and its stat cells showing dashes — so it can be re-activated. Its checkbox, Edit, and Delete buttons remain fully usable; saving an edit keeps it inactive and never steers what the other tabs show.
• The Projects section subtitle reads X of N projects active whenever the two counts differ.
• If the project selected in the top-bar dropdown is deactivated, the app switches to the first active project.
• Deselect all (0 active) locks every other tab: navigation is pinned to the Projects tab with a notice — All projects are inactive — tick at least one project's Active checkbox on the Projects tab — the same mechanism as the first-run lock. Tick any project (or Select all) to unlock.
• In demo mode, re-entering demo resets to the demo baseline, where every project is active.

Portfolio dashboard table

One row per registered project — active ones with live stats, inactive ones greyed with dashes (see the Active checkbox section above). Columns:

• Active — the include/exclude checkbox described above.
• Project — uppercase key + name. A red ⚠ dep badge appears when the project has an active dependency violation; an Inactive tag appears when the row's checkbox is unticked.
• Health — coloured pill: Healthy (green), At Risk (orange), Critical (red). Hovering shows the exact reason.
• Progress — bar + percentage of issues complete (done estimate ÷ total estimate).
• Forecast — the projected completion date, Never when the plan can't finish, or — when there is no projected date.
• Target — the project's computed target date, read-only: the same date that project's Target date card shows. It is the date on this project's own Add / Edit Project form; a date typed into the Target date card's gear is written to the same record, so the two can no longer differ (2026-09-03 — they did: 4 May in this table against 24 December on the card). When the project's target method is a manually fixed date, that date; otherwise the latest due date among its unfinished issues (or the last open sprint's end when the method is Latest sprint end). A project with no derivable target reads —. The Target Date field on the Add Project / edit form acts as the fixed date only when the project's target method is manual; it is no longer printed here raw.
• Slack — calendar days between the forecast and the computed target above (the same two dates shown in this row). Green when ≥ 0, red when negative.
• Scope — total estimate of in-scope issues, including done work, read-only. To model a scope change, use the What-If tab's All Projects view.
• Utilisation — % of active sprint capacity committed; green < 85, amber 85–100, red > 100.
• Team — count of active team members on the project, read-only. Team size comes from the registered members and the allocation matrix; to model adding or moving people, use the What-If tab's All Projects view.
• Alerts — two count badges from the alerts engine, blockers in red and warnings in amber; the word Clear in green when there are none.
• Estimation — % of active issues with an estimate. Green when more than 90% are estimated; orange when more than 10% are unestimated. (The project drill-down's Data Quality card shows the same figure, turning red when more than 20% of active issues are unestimated.)
• Actions — Edit, Delete.

The portfolio table is a read-only monitoring view: every cell reports a value, and the only interactive controls on each row are the Edit and Delete buttons.

Sorting

Every data column heading is clickable. The first click sorts by that column with the worst news first — most negative Slack first, Critical health first, highest Utilisation first, lowest Progress first. The second click reverses it. The third returns the table to registration order. A small arrow on the heading shows which column is sorted and which way it is running.

Columns with no "worst" end simply read in their natural order on the first click: Project alphabetically, Forecast and Target by date, Scope and Team by value. The two control columns — the Active tick and the Edit / Delete buttons — are not sortable, because ordering by them would fight the rule below that inactive rows sit at the bottom.

Rows whose cell in the sorted column is a dash sort after every row that has a value, whichever way the column is running.

Filtering by health

Three buttons above the table — All, At Risk & Critical, Critical only — narrow it to projects whose Health pill matches. The default is All. When a filter leaves nothing to show, the table body reads No projects match this filter and the buttons stay on screen to click back to All.

What sorting and filtering never do

• They are viewing choices only. Nothing is saved: reloading returns to registration order and All. They change nothing about the projects and write nothing to storage.
• Inactive projects always group at the bottom in registration order, whatever the sort — their stat cells are dashes, so ordering them among live rows would mean nothing. The health filter never hides them either, so an inactive project stays reachable for re-activation.
• The programme rollup row stays pinned at the bottom and its figures always cover the full active portfolio. The filter changes which rows are displayed, never what the rollup adds up.

Programme rollup row

When at least two ACTIVE projects exist, a footer row sums the active portfolio (inactive projects are excluded from every rollup figure):

• Program (N projects) — label.
• Health — Critical if any is critical, At Risk if any is at-risk, else Healthy.
• Average Progress.
• Total Scope — sum across projects, with unit suffix only if every project shares the same estimation mode.
• Total Team — count of team members engaged through at least one ACTIVE project. A member whose only allocations point at inactive projects is not counted (nothing is counted for an inactive project anywhere); a member registered with no allocations at all still counts — they belong to the programme without being tied to any project.
• Alerts — aggregate blockers and warnings.

Team Allocation Matrix

Below the project table, a members × projects grid. A couple of internal demo-only projects are hidden from this grid.

• Rows — every registered team member.
• Columns — every visible ACTIVE project (inactive projects' columns are hidden; their stored allocations are kept).
• Capacity column — base capacity per member: hours/week and points/sprint.
• Status column — running percent totals across visible projects, Σ Hrs: X% / 100% and Σ Pts: Y% / 100%. When over 100% the row is red with an "over by N%" callout; both units fire over-allocation independently.

Cell contents (read-only here)

Each cell shows two stacked values, read-only on this tab:

• Percent — the share of the member's capacity dedicated to that project (e.g., 50%). The unit matches the project's estimation mode — points for points-mode projects, hours for time-mode.
• Computed "= X" line — the absolute value the percent works out to at the member's current capacity, labelled with its period (pts/sprint for points, h/wk for hours).

To change an allocation, use the Alloc popover on the Team & Capacity tab, where editing either the percent or the "= X" value updates the other and saves immediately to the same program store. Storage is percent; both unit percents are persisted independently, so toggling a project's estimation mode never loses data.

Over-allocation

The matrix does not clamp totals. Over-allocation is preserved verbatim and surfaced through the Status column's red text, so the cost of putting Sarah on five projects is visible rather than silently capped. Forecasts respect the actual loaded allocation, so the consequences of over-allocation show up in the per-project utilisation and forecast columns.

Capacity-change live update

Changing a member's hours per week or points per sprint (in the Team & Capacity tab) immediately updates every "= X" display in this matrix and the Alloc popover, without re-entering any percents. A 60% allocation stays 60% across capacity changes — that's the intent the planner expressed, not the absolute number.

Feeds the program Delivery Forecast

The per-project allocation set here is also applied when the Delivery Forecast rolls a program up — the Program View on the Dashboard and Scope, and the All Projects sub-view on What-If. Each project is forecast on its team's allocated capacity, so a person split across projects counts at their share on each project rather than at full capacity on every one (which would make the program look faster than it is). Set the real split here for a true program forecast; a person left at 100% on more than one project is still counted in full on each.

Critical Chain panel

A collapsible Critical Chain section sits below the project table and shows the longest, most-constrained path of work that determines the programme end date. It is the same engine documented in ALGORITHMS section 7 (Critical Chain) — chain confidence, per-resource summaries, feeding paths, due-date risks, epic grouping, and team-pool overflow. When in Program All mode the chain is computed across every registered project; otherwise it is filtered to the selected project. The panel can also auto-fire its AI box once per chain (see ALGORITHMS section 17 — Critical Chain AI Box) when an API key is configured.

Cross-Project Dependencies

A list and an Add form below the matrix.

Dependency violations

When at least one declared dependency has the upstream forecast past the downstream target, a red alert box lists each violation: PROJ_A is blocked by PROJ_B — upstream finishes N days after PROJ_A's target.

Declared dependencies

A list of every upstream → downstream statement with optional description and a Remove button.

Add dependency form

Three controls:

• Upstream (blocks) — dropdown of ACTIVE project keys (inactive projects can't be picked; dependencies already declared on them stay listed but can't fire violations while inactive).
• Downstream (blocked by) — dropdown, same active-only rule.
• Description — optional human-readable reason.

Plus a + Add button.

Cascade rules

When a dependency violation fires:

• The downstream project is flagged as blocked, recording which project blocks it, when the upstream finishes, and how many days it is blocked.
• Its health is raised to At Risk if it was Healthy; left as Critical if already worse.
• If the upstream project itself has negative slack, the downstream's slack becomes min(downstream, downstream + upstream) so the late chain propagates: a 10-day-late upstream eats 10 days off the downstream's slack.

Removing a dependency clears the violation flag in the next analysis pass.

Empty / loading / error states

• No projects registered — the table still renders with its column headers and an empty body; the Add Project form above is where you start. (A brand-new install never lands here first: the one-page setup screen — Project Key, Board, Issue filter, Story Points vs Time — appears before any tab, and its More options link is what leads to this form with the typed values carried over. See the Getting Started Guide.)
• Loading — sprints and issues stream in; a spinner is shown when the underlying fetch is in flight.

Cross-cutting modes

• Estimation mode — when every project shares one mode, the rollup uses that unit; when they differ, the unit suffix is dropped from the rollup Total Scope cell to avoid mixing units.
• Sprint mode on/off — per-project; the sprint-only fields shift accordingly.
• Programs — selecting All projects aggregates every project at once; the Critical Chain section and other views use this to know whether to filter by the selected project.

How the numbers are computed

• Forecast — today + (remaining work ÷ average velocity) × sprint length in days. Velocity is the rolling average over the configured number of recent closed sprints; remaining is the sum of estimates on non-done issues.
• Slack — target − forecast in days. When a project has no projected date (or no target), Slack is blank and the cell shows —. Negative when forecast is past target.
• Health — Critical when slack < −14 days; At Risk when slack < 0 or utilisation > 120%; Healthy otherwise. Alerts do not influence health (they have their own column).
• Utilisation — remaining work ÷ forecast capacity × 100.
• Cascade slack propagation — when upstream slack is negative, downstream slack = min(downstream, downstream + upstream). See the ALGORITHMS Project Allocation section (Allocation in Scenarios and Cascades subsection).

Effects on other parts of the app

• The Active checkbox on each row decides whether that project exists anywhere else in the app: unticking removes it from the top-bar project dropdown, the Program view union, every program rollup and forecast, the Actions/Risks pickers, and the allocation surfaces, and stops its Jira board from being fetched — while this tab keeps the row for re-activation.
• The Team Allocation Matrix here and the allocation popover in Team & Capacity write to the same store. Edits in either place propagate everywhere.
• Selecting a project in the main app's project picker filters every other tab to that project; selecting All projects switches the Critical Chain section to programme-aware mode across the whole portfolio.
• Nothing on this tab is committed to Jira. The registered programme (projects + allocations + dependencies) is saved to the app's Atlassian Forge storage (scoped to your Atlassian account, removed on uninstall); cross-portfolio "what if" modelling is done non-destructively in the What-If All Projects view and is never written back.
• The cascade rules feed the per-project warning badges shown across the Sprints and Critical Chain panels.
• Each project's forecast and slack feed the Dashboard's Top Open Risks widget through the Deadline at risk detector.