Project Commander

🛠

Dashboard

Open the Dashboard tab for 4 stat cards: On Pace?, Delivery Forecast, Target Date, and Progress — each answering a key project question at a glance
On Pace? compares completed work to work due by today and shows the verdict (Ahead of pace / On pace / Behind pace) plus the delta — color-coded green or red (this card has no amber state)
Delivery Forecast shows the projected date, remaining work, and capacity to target — clipped at the target date, with capacity beyond it stated on its own line (N pts capacity available after target date) — plus the deliverability verdict (the matching sprint or Beyond Sprint N (+gap) appears on the Target Date card, not here). The card explains its inputs: amber notices when the Team/Effective model resolves to zero capacity, or when efficiency has not been measured yet, so nothing is discounted
Dashboard cards expose the relevant settings — pace measure, target date source (latest due / fixed), forecast (capacity) model, demand model, and scope growth
Delivery Forecast — capacity model × demand model grid — every capacity model (Each sprint's own setting, Effective team capacity, Team capacity, Velocity) against every demand model (Ignore / Respect dependencies, Resequence work, Critical Chain floor); each cell shows its finish date, gap to target, and on-target odds, shaded green / amber / red, with ★ Earliest / ▲ Latest flags and a detail panel for the selected pairing. Click a square to drive the Delivery Forecast card; the demand model is shared with the Scope and What-If tabs
Baselines — capture named snapshots of the plan; a timeline (forecast and target, with a period picker to focus on any date range) and a table track slip against target over time, with a per-baseline breakdown on hover; frozen snapshots saved per project and per program, rename/delete inline
Project Statistics table with one-line factors covering Scope, Team Capacity, Commitment vs Delivery, Estimate Accuracy, Team Balance, Dependency Conflicts, and Alerts — each row has tooltips and expand-for-detail
Widgets below the cards: Top Open Risks (highest-severity unresolved risks) and Velocity History (recent sprint velocity bar chart)
Plan Quality Warnings banner for overloaded resources, dependency conflicts, and external dates at risk — each links to the relevant tab
Weekly Digest one-page summary and full PDF export

💬

Ask

Ask sits in the tab bar, right of the project picker, on every tab. It opens a panel beside the screen you are on, headed Ask with the project key, and closes back to where you were
Type a question in plain words and the answer comes back as figures with labels: when the project will finish (the middle run, the best case and the odds of hitting a target date), every sprint's work against the capacity still ahead of it, every person's work against their capacity, what is blocked by work scheduled later, how much the scope has grown, velocity, epics, releases, time logged against estimates, the last closed sprint, and what needs attention first
Every figure is worked out by the app, by the same calculations the tabs are drawn from, so the same question gives the same numbers every time and an answer can be checked against the screen behind it. Which sprints are overcommitted? also draws a chart, one row per sprint
Before anything is asked, the panel lists Things it can answer: — click one to ask it. Clear empties the conversation
What-ifs change nothing. Ask what one more person would do, or what happens with an epic taken out, and an amber line stays on screen for as long as the what-if is in force, saying the answers are about a team that does not exist, with Back to the plan as it stands beside it
Nothing is written to Jira unless you say so. A change you ask for — move an issue to another sprint or the backlog, set its size, owner, priority, name, status or dates, create an issue, or create, date, start, complete or delete a sprint — is first described with what it does to the numbers, and is made only on a second press
An AI key is optional. When one is set up in Settings it is used only to read a question the plain words could not place and to put the figures into a paragraph, labelled with who wrote it; a paragraph naming a figure the app did not produce is thrown away. It never supplies a number
It will not tell you what people meant — comments, descriptions, mood — and says so, naming a question it can answer instead
Ask is in the app inside Jira, including on a Jira dashboard. It is not in the live demo or the web app

The Ask panel open: the question box at the top, the line saying every figure is worked out by the app and nothing is written to Jira unless you say so, and an answer to 'How much is done, and are we on pace?' giving the share done, the points remaining, whether the project is behind pace, and each sprint's work against its capacity

📋

Sprints

The Sprints tab lets you move issues between sprints with drag-and-drop — one at a time or select multiple with checkboxes to move in bulk. While you drag, a drop strip appears under every sprint naming the next sprint (or the Backlog), so even the bottom row of a sprint has a target right beneath it
Toggle List View to see every issue across all sprints in a single sortable, searchable table — ideal for bulk review without opening individual sprint rows
Two-button mode selector per sprint: Sprint (default) and a state-aware second button — future and active sprints show Status (live progress), closed sprints show Retro (final retrospective)
Tap the Deliverable / Tight / Overcommitted badge on any future or active sprint to open the sprint's confidence score, what is threatening it and what to cut — an active sprint judged on the work still ahead against the capacity left
Closed sprints report what happened: the header reads Committed · Done and the badge reads Delivered only when everything committed was finished, otherwise Delivered M of N
Inline editing in the issue table: click to edit Story Points, Original Estimate, Due Date, Assignee, Priority, or Summary — Enter to save, Escape to cancel. Zero-valued cells stay reliably clickable
Returning from a Jira link auto-refreshes sprint, project, and JQL data so edits made in Jira show up immediately
Quick-filter search inside any sprint card filters the issue table by key, summary, assignee, or status
JQL search box in the toolbar runs an ad-hoc Jira query and pulls matching issues into the view
Inline Create issue popover (project + type + summary) adds new issues to the backlog without leaving the tab
Load closed sprints on demand via the toolbar chip (Hidden / Last 5 / Last 20 / All) and run retrospectives on any past sprint
Every sprint shows a Deliverable, Tight, or Overcommitted badge plus demand vs capacity at a glance
See who's overloaded and who has room — click avatar chips in Demand by User to filter by person, expand for demand vs capacity bars
Auto-Level: split-button picker redistributes work across sprints using your chosen strategy (Priority, Size, Due Date, or Balanced — Balanced is the smart default that spreads load per assignee). A horizon picker limits how many sprints are rearranged (Next sprint / Next 2 / Next 3 / All); sprints beyond the horizon stay untouched. Each move shows a tooltip explaining why it happened (capacity, dependency, due date, lock, or horizon), and a summary panel above the board breaks down the deviations by reason. Compare All view, P50 / P85 forecast dates, skill-mismatch warnings, and optional one-click AI Review.
Velocity panel inline in the toolbar: sprint history, KPI tiles, and import controls, with effective-capacity efficiency per sprint
Sort by any column; drag to reorder issues within a sprint — custom order persists
Full sprint lifecycle: create, start, complete (with action-item and risk roll-over prompts), delete

Auto-Level in Action

Watch Auto-Level redistribute work across sprints with one click — then undo or accept the result.

🎯

Epics

The Epics tab provides a single unified overview table — all epics in one sortable, searchable view
Progress bars, point totals, assignee, start/due dates, and Jira status fetched directly from the backend
Sortable columns, search, and dynamic status filter to find what you need fast
Status by pace — Ahead of pace, On pace and Behind pace come from how much of the epic should be done by now, by the same rule as the Dashboard's On Pace card, pointed at the epic's own issues and dates; the Why column states the comparison and a sortable Pace column carries the gap, so the worst-slipping epic rises to the top. A Behind epic raises an alert.
Scope change tracking per epic — see what was added since the baseline
Expandable rows to see child issues with their details

🎲

What-If

The What-If tab has 4 distinct sliders: Velocity, Issue Estimation, Scope, and Capacity — each directly affects your projected delivery date in real time
Cascade chart with an optional per-user breakdown and an optional cross-hatch overflow — turn them on to see who is over capacity and when
Direct connection to delivery forecast — sliders update the projected completion date instantly
Monte Carlo simulation with S-curve probability distribution for data-driven stakeholder forecasts — five cards on the Sprint and Project Simulation views: target week/sprint, on-target probability, Finish on Time? (Yes / Maybe / No from the run probability), expected slip, and a 0–100 Feasibility score (High / Medium / At Risk / Critical)
Sprint / Project / All Projects sub-views — sprint-based, weekly time-based, or the whole program rolled up
Program Simulation (All Projects) — the chance of the whole program finishing on time (on time only if every project is), the expected slip, a probability-over-time curve, and a weakest-links table of each project's own odds, worst first
Cascade overflow checkbox (on by default) carries work that does not fit a sprint into the next one; untick it to see each sprint on its own

What-If & Monte Carlo Video

Watch how changes to velocity, estimation, scope, and capacity affect your delivery date — then see a Monte Carlo simulation in action.

👥

Team & Capacity

The roster table first, a summary strip beneath it (N people overcommitted this period · N on the team), and two folding sections under Availability detail: Time off calendar and Company holidays
Per-member status badges: OVERCOMMITTED, OPTIMAL, AVAILABLE, UNDERLOADED — see team balance at a glance
Add team members through an in-app + Add member dialog with their share of the selected project; a new project's team is pre-filled from its assignees, each at 100% of that project
Configure each member's capacity, utilization %, and time off — capacity updates everywhere automatically. Nothing typed is no capacity: the app never assumes a figure for anyone
Period selector (Sprint — named Period when Sprint Mode is off — Weekly, Biweekly, Monthly, Quarterly, Yearly); with Sprint chosen, a dropdown picks the sprint by name or All sprints at once, plus a Populate weeks button to bulk-fill capacity at the current rate
Show total / Per selected project toggle: switch between aggregated capacity and project-scaled rows so the numbers reflect what each member has dedicated to one project
Alloc column on every row: each member shows Hrs: X% / 100% and Pts: Y% / 100% across the program's projects (red when over). Click the cell to open a popover with per-project percent inputs paired with an editable “= X pts/hrs” computed value — edit either, the other follows. Î£ chips at the bottom of the popover sum the percents per unit and flag over-allocation independently for hours and points
Percent allocations survive capacity changes: bump a member's Pts/Wk or Hrs/Wk and every “= X” display in their popover recomputes from the new capacity without re-entering the allocations — a 60% allocation stays 60% across capacity changes
Click dates on the calendar to mark PTO; Ctrl+click toggles individual days, Shift+click selects a range. Add company holidays with optional recurring flag
Capacity data feeds Dashboard forecasts, What-If scenarios, and sprint planning simultaneously — one source of truth
The Demand vs Capacity chart now lives on the Scope tab, sitting next to the scope timeline that shares its data

📈

Scope

The Scope tab rebuilds changelog-based scope history from Jira issue changelogs — accurate, auditable tracking of exactly when and how scope grew
Stat cards across the top: Burned & Remaining, Scope on start, Scope now, change %, Start date (Fixed / Earliest start / Earliest due / Earliest sprint start), Target date (Fixed / Latest due / Latest sprint end), Delivery Forecast, and Capacity to target
Burndown and burnup on the same chart: Scope, Remaining, Ideal Burndown, plus Burnup, Ideal Burnup, and Burnup Forecast. Teams that report progress as work completed read the burnup; teams that report it as work remaining read the burndown — both views agree because they come from the same data
Forecast strategy picker (Priority / Size / Due Date / Balanced) decides what order to burn down; the separate Capacity model picker (Each sprint's own setting / Effective team capacity / Team capacity / Velocity) decides how fast. Compare All overlays every strategy on the same chart
Confidence band around the forecast trace: Off, Historical variability (width comes from your team's own velocity, scope-change, and estimate-vs-actual stddevs), or Monte Carlo (P10–P85 from ~600 simulation runs)
Per-user filter chips, Sprint Markers toggle, Include Backlog toggle, and period grouping: All Time, Weekly, Biweekly, Monthly, Quarterly, Yearly, or Sprint (buckets by the project's actual sprint windows)
Scope growth rate modeling — Average over period or Manual rate — factors in how fast scope is expanding for realistic forecasts
Demand vs. Capacity chart (collapsible) below the timeline: period capacity vs period demand over time, sharing the same target and projected-completion markers as the Scope chart
Weekly Breakdown table (collapsible): one row per period with Issues, Added, Burned, and cumulative Completed — expand any row to drill into the issues that contributed in that window

Below the timeline, the collapsible Demand vs Capacity chart tests feasibility week by week — whether the team's available capacity can absorb the demand on the books. A cumulative over-by headline calls out infeasible periods; hover any week for weekly capacity, demand, scope, completion, and the exact overload.

Demand vs Capacity section on the Scope tab, open: daily capacity and daily demand across the whole project, the cumulative capacity, cumulative demand and Over by strip above the chart, and the Resource Breakdown table below it with each person's load and a status pill

🚨

Alerts

The Alerts tab runs forty checks over every issue in the project — the ones in sprints, the ones in the backlog, and anything else the project’s issue filter returns
Eight groups, every check on screen at once under its heading: Dependencies (blocked by work that comes later, by work already finished, circular dependencies, child due after its parent, blocked by work in another project), Something missing (no epic, no due date, no start date, no estimate, estimated at zero, unassigned, the same summary twice), Dates and sprints that disagree, Estimates (fourteen checks on estimates and time logged), Looks finished, is not, Scope and capacity, Delivery risk and Risk strategy
A check that found nothing still shows, with a green zero — so a check that ran and found nothing can never be mistaken for one that did not run
Circular dependencies are drawn as the loop, first key equal to last, and count as an error: nothing in a loop can start until something in it finishes
Severity buttons (All / Errors / Warnings) and a filter box that narrows the list by issue key or text — and never move the counts, because those are the state of the project rather than of the view
Show only found issues, a checkbox on the tab itself, for a reader who wants the short list
Dismiss a finding and it leaves its check, the count and the badge — into a folded Dismissed list that says which check found it, with Restore to put it and the count back
Choose which checks run, and in what order, from the Settings gear: which sprints they are asked about, whether the backlog is included, what each of your status columns means (including waiting on something, a fourth group Jira does not have), and checks of your own written as questions in Jira’s search language
a Create risk button opens the Risks tab with a new-risk form pre-filled (probability, impact, source category); each finding also has a Create action button
The badge counts exactly what the list shows — the badge, the tab’s own header, the Dashboard’s statistics row and the weekly digest are one calculation, so they cannot disagree; click any finding to jump straight to the issue in Jira

☑

Actions & Risks

The Actions tab tracks follow-through items raised during sprint reviews, retrospectives, planning, or alert triage. They sit in two tables, OPEN and DONE, with a column each for the assignee, where the action came from, and its priority
Action fields: title, description, owner, originator (defaults to your name), priority, scope (program / project / sprint), status, optional links to related risks
Filter by status, scope, originator, or assignee; sort by date opened or priority. Mark done and Reopen buttons handle premature closures cleanly. Dated comments form a running log per action
The Complete Sprint dialog walks each open action and prompts you to mark it done, roll it over, or close it — nothing falls through the cracks
The Risks tab lists Manually Entered risks (the ones you typed) first, then the folded AI Generated suggestions (worked out by rules from your project's own data — no AI service is called) and the Accepted AI Generated risks, with closed risks folded away at the foot. Detectors raise items like velocity drops, scope creep mid-sprint, single-point-of-failure resourcing, and cross-sprint dependency conflicts
Each risk has Probability (1–5) × Impact (1–5) with derived Severity, RACI owners (Accountable, Responsible, Consulted, Informed), Originator, and status (Open or Closed) — separate from the response strategy (Mitigate / Accept / Transfer / Escalate / Defer / Avoid)
Response strategy on every risk — pick from Avoid, Mitigate, Transfer, Accept, Escalate, Defer (or leave Undecided). Strategy-specific required fields (escalation owner, review-by date, rationale) plus a full audit trail of strategy changes
One-click accept — accepting an AI suggestion creates the risk instantly, with the detector-specific mitigation actions attached automatically and a full audit trail. The new risk lands under Accepted AI Generated with the normal edit, close, action and comment controls
Filters: Source (All / Manual / AI), Status, Strategy (All / Undecided / Avoid / Mitigate / Transfer / Accept / Escalate / Defer), Scope (All / Program / Project / Sprint). On-tab toggles: AI risk suggestions and Auto-close risks when all mitigation actions complete
The Dashboard's Top Open Risks widget adds a strategy mix bar (e.g. "4 mitigate · 2 accept · 1 escalate · 3 undecided") and sorts Undecided and Escalate risks above Accept at the same severity, so attention-demanding items surface first
The Complete Sprint dialog lists every risk whose linked actions are all complete and offers one-click Mark Closed — the register stays current without manual cleanup
Badge counts on both tabs show open items at a glance

Actions tab: the OPEN and DONE tables, each row carrying the action, its assignee, where it came from and its priority, with Mark done, Edit and delete on the row

Risks tab: AI-generated and manual risk register with probability, impact, severity, and RACI owners

📅

Timeline

Every epic and issue as a bar on a calendar — the done share filled in, finished work in green, and work placed by a date somebody typed drawn striped, so a typed date is never mistaken for a worked-out one
Columns are your sprints, named and dated, with projected sprints past the last planned one marked as projected. A project with Sprint Mode turned off gets its own planning periods instead. Scale by sprint, week or month, with a zoom slider along the bottom of the chart
Today, the target date and the forecast date are marked on the chart, the likely-finish range shaded behind them and the stretch past the target hatched — the same dates as the Delivery Forecast, Target Date and On Pace cards sitting above the chart, because they come from the same calculation
Twelve sortable columns down the left — Key, Summary, Assignee, Sprint, Points, Remaining Est, Original Est, Status, Type, Start Date, Due Date and Progress — with a draggable divider between the table and the chart, and both panes scrolling together
Group by Epic, Person, Project, Sprint, or nothing at all, with one arrow that folds every band or opens them all again. Ungrouped, the list runs earliest due date first, an issue with no due date of its own using its epic’s
Dependency arrows from Jira’s own “blocks” links. An arrow that points backwards — work waiting on work scheduled later — is drawn dashed, so the conflict is visible on the picture and not only in a list
The critical chain laid over the same chart. Tick one box and everything not on the longest run through the plan fades away. The tab says which of the two things the chain is: a run of dependent work, or the busiest person’s own queue
The date each issue is committed to is a marker on its own row, and where the bar runs past it the days late are measured and labelled on the row
A person over capacity in the stretch a bar falls in gets a red ring around the bar, so overload shows up on the chart itself
Shared capacity, in one press. Every registered project on one chart, one lane per person, one queue each. Somebody booked solid across two projects stops looking comfortable on both — the portfolio views in the other tools stack one chart per project and cannot see it
Hover any bar for why it starts when it does — waiting on a blocker, waiting for the person who has it, its epic’s start date, timed to finish on its due date, or a date somebody typed — along with its owner, epic, sprint, size, forecast dates and what it blocks
Edit on the chart. Drag a bar sideways to set its start and due dates, drag either end to change the size of the work, drag it into another person’s lane to reassign it, or change Assignee, Points, Status, Start Date and Due Date in the table. Nothing reaches Jira until you press Update Jira and confirm the list of changes, issue by issue and field by field
“What this chart is telling you” — a folding notice above the chart that says in plain words what the picture is showing: which start rule is in force, who is over capacity and why, which dependencies point backwards, which dates were typed rather than worked out, and what the critical chain adds up to

Grouped by epic, each epic gets its own span across the top of its issues, drawn red where it runs past its due date. The three cards above the chart — On Pace?, Delivery Forecast and Target Date — are the app’s own, so the dates on the chart and the dates on the cards can never disagree.

Timeline tab grouped by epic: sprint columns with Today marked, epic spans, issue bars carrying their point sizes, committed-date markers, a days-late measurement, and a twelve-column table down the left

🏙

Projects

The Projects tab shows every project's Health (Healthy / At Risk / Critical), Progress %, Forecast date, Target date, Slack days, Scope, Utilization, Team size, Alert counts, and Estimation coverage in a single table — everything visible without drilling in
An Active checkbox on every row (plus Select all / Deselect all) chooses which projects the app looks at — untick a project and it disappears from every view, picker, forecast, and rollup and its board is no longer fetched, while its settings, allocations, and dependencies are kept for the moment you re-tick it
A Program totals row at the bottom rolls weighted averages across every active project
Switch the header selector to Program view and every tab — Dashboard, Scope, Alerts, Risks, Actions, Epics, Team & Capacity, What-If — unions data across every active project you manage
The portfolio table is a read-only overview — Target, Scope, and Team are display-only (a project's settings change on its Edit form). Model program-level what-if changes (capacity, scope, velocity) in the What-If tab's All Projects view, which never writes back to Jira
+ Add Project requires Project Key and a JQL Filter, plus a Board ID while Sprint Mode is ticked (untick it and the board is not needed: the work comes from the filter and the team is filed under the project key); Edit and Delete buttons sit on every row, with confirmation before delete
Team Allocation Matrix (collapsible): a grid of every team member × every project. Each cell shows the percent of capacity dedicated to the project plus a computed “= X pts/hrs” line, read-only here. Hours and points percents are independent. Status column shows Σ per-unit totals against 100% and flags over-allocation per unit independently. Allocations are edited in the Team & Capacity tab's Alloc popover (where editing either the percent or the “= X” value updates the other, and setting a cell to zero while the member still has unfinished work prompts for confirmation)
Critical Chain (collapsible) calculates the resource-constrained sequence that drives the earliest possible finish date — dependencies plus the fact that the same person cannot be in two places at once
Cross-Project Dependencies (collapsible) lets you declare that one project blocks another. Upstream slips past a downstream target date trigger a violation flag

The Critical Chain panel shows the resource-constrained sequence that sets the earliest possible finish date — dependencies plus the fact that the same person can’t be in two places at once. The chain (solid blue) is the longest weighted path through the combined graph of dependency edges and resource-queue edges; feeder paths (orange) merge into it; idle-resource gaps (dotted) show where the schedule is paused on availability rather than blockers. The assignee owning the most chain work is the bottleneck.

Features