Project Commander

1. Installation

Project Commander is a Jira Cloud app that can be accessed as a full-page app or as a dashboard gadget.

Installing from Atlassian Marketplace

1. Go to the Atlassian Marketplace
2. Search for "Project Commander"
3. Click Get it now
4. Select your Jira Cloud site
5. Confirm the installation

Accessing the Full-Page App

1. In Jira, click Apps in the top navigation menu
2. Select Project Commander from the dropdown
3. The full-page app opens with all features available

Adding the Dashboard Gadget

1. Navigate to a Jira dashboard
2. Click Add gadget
3. Search for "Project Commander"
4. Click Add gadget
5. The gadget will appear on your dashboard with the same features as the full-page app

2. Standalone Web App

Don't want to install anything? The standalone web app lets you try Project Commander with your own Jira data directly in your browser — no Atlassian Marketplace installation required.

Step 1: Enter Your Beta Access Code

Visit projectcommander.app/app and enter your beta access code. Or click Try Interactive Demo to explore with sample project data — no account needed.

Step 2: Register

After entering a valid code, provide your name and email. Click Start Using Project Commander.

Step 3: Connect to Jira

The Connect page has two tabs: Connect Jira and Upload CSV. To connect to Jira, enter your site URL, email, and an API token. Check the Terms of Use checkbox and click Connect to Jira. Or click Try Interactive Demo at the bottom to explore with sample data.

Security & Credentials

• Your credentials are stored only in your browser's session storage and are cleared when you close the tab
• Credentials are never transmitted to or stored on our servers
• The API proxy only forwards requests to *.atlassian.net domains
• You can revoke your API token at any time at id.atlassian.com

Disconnecting

Click the Disconnect button in the top banner to end your session and clear your credentials from the browser.

3. CSV Import (Standalone Only)

The standalone web app can import project data from any CSV file — no Jira required. On the Connect page, select the Upload CSV tab.

Step 1: Upload Your File

Drag and drop a CSV file or click to browse. The file must have a header row. Common formats from Jira, Azure DevOps, Asana, Monday.com, and spreadsheets are supported.

Step 2: Column Mapping

Project Commander auto-detects columns like Summary, Status, Story Points, Start Date, Due Date, Assignee, Priority, and Sprint. Review the mapping and adjust any fields that weren't detected.

A Summary column is required. All other columns are optional. If no Sprint column is present, the app switches to Tasks mode — a flat list with date-based planning instead of sprint lanes.

Step 3: Status Mapping

Map your status values (e.g., "Open", "In Review", "Closed") to three categories: To Do, In Progress, and Done. The app auto-guesses based on common status names.

Step 4: Confirm & Import

Review the summary and click Import. Your data is stored locally in the browser (IndexedDB) — nothing is sent to a server.

Tasks Mode (No Sprints)

When your CSV has no Sprint column, the Sprints tab becomes the Tasks tab. Issues appear as a flat list sorted by date. All other tabs (Dashboard, What-If, Team & Capacity, Scope, Alerts) work normally using weekly time buckets instead of sprints.

Work Leveling

In CSV mode, the Level Work banner appears above all tabs. Click it to automatically redistribute task dates so no single week exceeds your team's capacity. The algorithm respects priorities and dependencies. After leveling, you can Accept the changes or Cancel to revert. An Undo option is available after accepting.

Work Leveling can be disabled in Settings → Advanced → Enable Work Leveling.

4. Getting Started

When you first open Project Commander, click the Settings gear icon (⚙) in the tab bar to configure the app. Three settings determine what the app shows you.

Step 1: Set Your JQL Filter

The JQL filter defines which Jira issues appear across all tabs. Enter any valid JQL query, for example:

• project = PROJ — all issues in a project
• project = PROJ AND sprint in openSprints() — only open sprint issues
• project = PROJ AND labels = "release-2.0" — issues with a specific label

All tabs share the same issue data from this filter.

Step 2: Enable Sprint Mode (Optional)

If your team uses Jira sprints, enable Sprint Mode and select your Board. The app searches your Jira Scrum boards — type to filter, then click to select. If the app is opened from within a Jira board, the board is auto-detected.

Sprint Mode unlocks the Sprints tab (sprint planning, drag-drop, auto-level) and the What-If tab. All other tabs work with or without Sprint Mode.

Step 3: Choose an Estimation Mode

Choose how your team measures work:

• Points — uses Jira story points. Capacity defaults to a manual limit, or can be auto-calculated from team Points Per Sprint.
• Time — uses Jira time tracking (remaining estimate). Capacity is auto-calculated from team availability configured on the Team & Capacity tab.

Step 4: Save

Click Save Configuration. The app will load your data and display the appropriate tabs.

Tab Overview

Tab	Purpose	Requires
Dashboard	Single-screen project health overview with key metrics and navigation	Always visible
Sprints	Sprint planning with drag-drop, auto-level, and capacity tracking	Sprint Mode ON + Board selected
What-If	What-if analysis and Monte Carlo simulation — Sprint view (by sprint) and Project view (by week)	Always visible (Sprint view requires Sprint Mode ON)
Team & Capacity	Team capacity, time off, holidays, and demand vs capacity chart	Always visible
Scope	Scope and burndown timeline chart with delivery forecast	Always visible
Alerts	Issue problems and dependency analysis	Always visible
Epics	Epic progress, forecasts, scope growth, and cross-epic dependencies	Always visible

5. Dashboard Tab

The Dashboard is your project's home screen — a single view that answers the fundamental question: "Are we on track?" It surfaces the current project status, the delivery forecast, plan quality warnings, diagnostics, and suggested actions. It is always visible as the first tab, regardless of Sprint Mode or Board settings.

Stat Cards

The top of the Dashboard shows four stat cards that summarize your project at a glance. Each card is clickable — it navigates to the relevant detail tab.

Current Status

Of the work due by today, how much is done? Compares completed work to work that was planned to be done by now (based on issue due dates or sprint end dates):

• Ahead (green) — completed work exceeds planned work by more than 5%
• On pace (green) — completed work is within 5% of planned work
• Behind (red) — completed work is more than 5% below planned work

Shows completed and planned-by-now totals in your configured units. A gear icon opens a checkbox to include all Done work, not just work that was planned by today.

Delivery Forecast

Shows the projected completion date using the per-sprint, per-user simulation engine. Click the gear icon to open per-card settings with two controls:

• Delivery Projection Method dropdown — Sprint Capacity, Effective Capacity, Team Capacity, or Velocity. The system auto-selects the first available method. See Section 6: Delivery Forecast for how each method works.
• Scope Growth Method — enable with the checkbox, then choose Average (historical growth rate) or Manual (fixed rate in pts/wk or hrs/wk). See Section 7: Scope Growth.

Below the projected date, the card shows Remaining (total estimated work not yet completed) and Capacity to target (total team capacity available from now until the target date). When Remaining exceeds Capacity to target, the forecast date will be past the target date. When one team member is driving the delay, the card shows a bottleneck indicator.

Target Date

The deadline you are measuring against. Two choices:

• Latest issue due date — auto-derived from the latest due date across all issues in scope
• Fixed date — a manual date picker where you set a specific deadline

The target date is shared across the Dashboard, What-If, and What-If (Project view) tabs. Setting it in one place updates all three.

Progress

Overall percentage of work completed across all issues in scope. Calculated as sum(estimates for Done issues) ÷ sum(all estimates) × 100. Falls back to issue count if no estimates exist.

Plan Quality Warnings

A warnings banner appears above the stat cards when the sprint plan has issues that undermine forecast reliability. The banner surfaces problems you should address to get a trustworthy delivery forecast. When all warnings are resolved, the banner disappears and the forecast is based on a realistic, leveled plan.

Warning Types

Overloaded resources: One or more team members have more work assigned than their capacity allows across one or more sprints. The forecast reflects this overload honestly — it will show a later date because work overflows sprint to sprint — but the plan itself is unrealistic until rebalanced.

"3 team members overloaded across 2 sprints — Auto-Level to rebalance"

Dependency conflicts: Issues are ordered across sprints in a way that violates their dependencies — for example, a blocker in Sprint 6 that blocks work scheduled in Sprint 5. The forecast assumes work proceeds as planned, but dependency violations may cause delays that are not captured in the simulation.

"2 dependency conflicts in Sprints 5-6 — review in Sprints tab"

External dates at risk: Issues with hard, externally-driven deadlines (locked issues with manually-set due dates) are placed in sprints that end after their deadline. These represent commitments to customers, regulators, or stakeholders that the current plan will miss.

"1 externally-constrained issue at risk of missing its deadline"

Recommended Workflow

The warnings guide a natural planning workflow:

1. Auto-Level — balance sprints and resources so no one is overcommitted.
2. Accept — apply the leveled plan.
3. Lock issues with external constraints so Auto-Level won't move them.
4. Sync Due Dates — set issue due dates from sprint placement. Locked issues keep their externally-driven dates.
5. Resolve dependency conflicts in the Sprints tab.
6. Review the forecast — now based on a realistic, leveled plan with dependencies honored and external dates respected.

Diagnostics Table

A single expandable table showing all project health factors. Click any row with a caret to expand for a detailed breakdown.

Factor	What It Shows	Calculation
Scope	Project-wide scope growth percentage since start	(current scope − original scope) / original scope × 100. ● Green if ≤10%. ● Amber if 11–25%. ● Red if >25%.
Team Capacity	Team utilization percentage	remaining demand / total capacity × 100. ● Green if 60–90%. ● Amber if <60% or 91–110%. ● Red if >110%.
Delivery Rate	Percentage of capacity actually delivered, with trend	average(completed / capacity) across recent sprints, with trend direction (improving, stable, declining). ● Green if ≥85%. ● Amber if 65–84%. ● Red if <65%.
Estimate Accuracy	Time spent vs original estimate — are estimates reliable?	total time spent / total original estimate × 100. ● Green if 80–110%. ● Amber if <80% or 111–130%. ● Red if >130%.
Team Balance	Workload distribution across team members	Compares each member’s load% (demand / capacity × 100). ● Green if all members 50–100%. ● Amber if any member >100% or <50%. ● Red if any member >115% while another is <60%.
Dependency Conflicts	Cross-sprint dependency violations	Counts issues blocked by something in a later sprint. ● Green if 0. ● Amber if 1–2. ● Red if ≥3.
Alerts	Error and warning counts from the Alerts tab	Errors: done-with-remaining, dependency conflicts, circular dependencies. Warnings: overdue, child-after-parent, missing dates, missing estimates. ● Green if 0 alerts. ● Amber if warnings only. ● Red if errors present.

Each row shows a status dot (green/amber/red/black) and a plain-language explanation.

Each factor row is expandable — click to see a detailed breakdown of the calculation, contributing issues, and trend data.

Weekly Digest & Export

Two buttons appear in the top-right corner of the Dashboard:

• Export Dashboard — downloads a snapshot of the dashboard as a PDF file.
• Weekly Digest — opens a preview of a comprehensive weekly project summary that you can export as a PDF to share with stakeholders.

The Weekly Digest includes:

• Status badge — determined by the project health score (a weighted composite of diagnostics factors) combined with delivery forecast risk:
  • CRITICAL (red) — health score < 30%
  • AT RISK (amber) — health score 30–59%, or the delivery forecast projects a late date
  • ON TRACK (green) — health score ≥ 60% and no delivery risk detected
• Status reason — one-line explanation, e.g. "Delivery projected 5 days late (Mar 28 vs Mar 23 target)"
• Key numbers — Completion %, Average Velocity, and Alert count
• What Changed This Week — scope creep, efficiency changes, completion progress, and velocity trends with up/down indicators
• Needs Attention — all active alerts with severity-colored badges (BLOCKED, RISK, SCOPE, CAPACITY, MISSING, DEPENDENCY, OVERDUE) and descriptions
• Outlook — forward-looking summary with velocity projection, remaining backlog, estimated sprints and clearance date

AI Insights / Ask AI

A collapsible panel that auto-generates an AI analysis of your project status. Each bullet point is prefixed with PROJECT STATUS: or TEAM & PLAN HEALTH: and is expandable for more detail. Recommendations are listed separately.

Below the insights, an Ask AI section lets you type natural-language questions about your project. For example: "Which sprints are at risk?", "Who is overloaded?", or "What should I focus on this week?" The AI receives your project context — sprints, issues, capacity, velocity, and demand vs capacity data — and returns a focused answer.

This feature requires an AI API key configured in Settings (see Settings Reference).

6. Delivery Forecast

The Delivery Forecast predicts when your project will finish based on the team's throughput and the remaining work. It appears as a stat card on both the Dashboard and What-If tabs, and drives the projected completion date throughout the app.

Click the gear icon (⚙) on any stat card to expand its settings. The Delivery Forecast card reveals the Projection Method dropdown and Scope Growth Method controls.

How It Works

The forecast walks through each future sprint (or week, if Sprint Mode is off) and simulates work being completed using a stepped per-sprint, per-user simulation:

1. For each future sprint, the system calculates each team member's available capacity — how much work they can realistically complete in that sprint, accounting for their configured hours, utilization rate, holidays, and PTO.
2. Each team member's assigned issues are consumed up to their capacity for that sprint. Work they cannot finish overflows to the next sprint.
3. Unassigned issues are consumed by whatever spare capacity remains after each member's assigned work is handled.
4. The forecast date is the end of the sprint where all work — assigned, unassigned, and overflow — is fully absorbed.

If one team member is overloaded while others have spare capacity, the forecast reflects this honestly. The project finishes when the last person clears their queue, not when the team average says so.

Throughput Methods

The Delivery Projection Method dropdown controls how each team member's per-sprint capacity is calculated. All four methods use the same stepped simulation — only the source of the capacity number differs.

Sprint Capacity

Uses the capacity set for each sprint. Each sprint can have its own capacity override — a custom number, team-calculated capacity, or effective capacity — configured in the Sprints tab. Per-user capacity can be set individually for each team member within each sprint using the inline capacity editor in the per-user table. Sprints without an override use the default capacity from Settings. When per-user limits are not set, the sprint limit is split proportionally based on each member's team capacity.

This represents what the PM has budgeted for each sprint.

Team Capacity

Uses the bottom-up calculation from the Team & Capacity tab — each member's hours per week, multiplied by their utilization percentage, minus holidays and PTO for that sprint. This represents what the team can actually work based on their availability.

Effective Capacity

Applies each team member's historical efficiency rate to their team capacity. If a member typically delivers 80% of their planned capacity, their effective capacity is their team capacity multiplied by 0.8. This is the most realistic method for teams with established delivery history.

Velocity

Uses each team member's actual average delivery rate from completed sprints. If Alice has averaged 12 points per sprint over the last 5 sprints, that is her projected throughput — adjusted to zero for any sprint where she has PTO. This method is purely empirical: it uses what the team has delivered, not what they are configured to deliver.

The system selects the first available method in this order: Sprint Capacity, Effective, Team, Velocity. You can override by selecting a different method from the dropdown.

Per-User Capacity in the Sprints Tab

Each sprint card shows a per-user table with columns for Member, Demand, Capacity, and Status. The Capacity column is editable — click on a member's capacity value to set their individual capacity for that sprint. This override is saved per-user per-sprint and takes priority over the global settings default.

This allows fine-grained control: you can give Alice 20 points of capacity in Sprint 5 (she's focused on this sprint) and Bob only 10 (he's splitting time with another project), even though both have the same global default.

Remaining and Capacity to Target

Below the projected date, the forecast card shows:

• Remaining: Total estimated work not yet completed across all issues in scope.
• Capacity to target: Total team capacity available from now until the target date, summed across all future sprints.

When Remaining exceeds Capacity to target, the forecast date will be past the target date.

Bottleneck Detection

When the forecast is driven by one overloaded team member rather than overall team capacity, the forecast card identifies the bottleneck:

May 30, 2026 (Sprint 10) — 6 days late
Bottleneck: Alice — overloaded in Sprints 5-7

This tells you WHY the date is late and WHO to rebalance, so you can make an informed decision about whether to reassign work.

Sprint Mode Off

When Sprint Mode is off, the forecast uses weekly steps instead of sprint steps. Each week's capacity comes from team member settings (hours per week multiplied by utilization, minus any PTO or holidays that week). Issues are bucketed by their due dates into weeks. The simulation and throughput methods work identically — only the time unit changes from sprints to weeks.

7. Scope Growth

Scope growth models the rate at which new work enters the project. When enabled, it reduces the effective capacity each sprint by the amount of new work expected to arrive, extending the forecast accordingly.

How Scope Growth Is Calculated

The growth rate represents the net new work added per week: issues created minus issues removed (cancelled, rejected, or marked as won't do). Done issues are counted as additions — they were real scope when created. Only issues in removed statuses are subtracted.

The calculation uses issue creation dates and the current estimation mode:

• Points mode: Story points of issues created within the period.
• Time mode: Original estimate (with remaining estimate as fallback) of issues created within the period.

Growth Models

Average (Avg over period)

On the Scope tab, this computes the historical growth rate over the selected period (Weekly, Monthly, All Time, etc.). On the Dashboard, it uses the project's full history from the earliest issue creation date to today. Both tabs use the same underlying calculation.

Manual

You specify a fixed growth rate in points or hours per week. Use this to model specific scenarios — for example, "what if we add 10 points of new work every week?"

How Scope Growth Affects the Forecast

Growth adds to the unassigned demand pool each sprint:

unassignedDemand += growthRate × sprintWeeks

This new work competes for spare team capacity after assigned work is handled. If growth exceeds the team's total throughput, the forecast shows "Never" — the team cannot finish because new work arrives faster than it is completed. The method remains selectable so you can see the impact and compare against other methods.

8. Sprint View

The Sprints tab is where you plan and manage your work across sprints. Each sprint appears as a collapsible card showing its issues, capacity, and team workload. To see the Sprints tab, enable Sprint Mode and select a Board in Settings.

What You See

The page is organized top to bottom:

1. Action bar — Dependencies button, refresh, and other actions
2. Toolbar — a unified row with collapsible sections (click each label arrow to expand):
   • Velocity — historical sprint performance chart and KPI tiles (see Velocity Tracking)
   • Demand by User — colored chips per assignee showing workload across all sprints. Click a chip to filter sprints to that person.
   • Auto-Level — strategy pills for auto-leveling (see Auto-Level)
   • Collapse/Expand All — toggle all sprint cards and backlog open or closed
   All sections start collapsed by default.
3. Create Sprint — a dedicated row for creating new sprints
4. Sprint cards — one card per sprint, in board order. Each card has a compact header row and an expandable details panel. Below the header is the issue table.
5. Backlog — if Include Backlog is on, a backlog section appears at the bottom with unscheduled issues.

Sprint Card Header

The header row gives you a quick summary without expanding anything:

• Grab handle — drag to reorder sprints on the page
• Chevron — expand or collapse the issue table
• Lock icon — lock the sprint so Auto-Level won't touch it
• Sprint name and dates
• Deliverability badge — a colored badge showing sprint health:
  • DELIVERABLE (green) — demand ≤ capacity
  • TIGHT (amber) — demand within 10% of capacity
  • OVERCOMMITTED (red) — demand exceeds capacity
• Header stats — compact inline display of demand, capacity, done %, and scope delta. If remaining demand exceeds capacity, the scope value turns red with a positive number (e.g., "Scope +12 pts").
• Progress bar — a small indicator showing how much work is done. In Points Mode this shows completed points out of total. In Time Mode this shows how much of the original estimate has been worked off.
• Action buttons — Sync Dates, Start, Complete, Delete, Refresh (which buttons appear depends on the sprint state)
• Sprint Risk Badge (future sprints only) — a colored badge showing dependency risk:
  • 🟢 No Risk — no incomplete blockers in earlier sprints
  • 🟡 Medium Risk — some blockers in earlier sprints are still in progress
  • 🔴 High Risk — some blockers in earlier sprints have not started yet
  The badge checks each issue's blocking dependencies: if a blocker is in an earlier sprint and isn't done, the risk is "medium" if the blocker is in progress, or "high" if it hasn't started. The sprint's overall risk is the worst of all its issues.

Sprint Details Panel

Click the Sprint Details toggle below the header to expand additional information:

• Goal — the sprint goal. Click the text to edit it; changes save to Jira automatically.
• Scope Creep (active sprints only) — compares the sprint's current scope to what it had when it started. Shows something like "Scope: 40 pts → 52 pts +30%". Click it to see exactly which issues were added or removed mid-sprint.
• Capacity settings — the capacity value (click to edit), unit label, and a dropdown for controlling the capacity source: Settings default, Capacity settings/Team, or Custom for sprint/Custom (see How Capacity Works below).
• By User — a collapsible user filter with two modes:
  • Collapsed — colored avatar circles for each person. Click any avatar to toggle that user's visibility — excluded users turn gray and their issues are hidden from the sprint. A red ring means over capacity, green means within limits.
  • Expanded (click the chevron) — full user rows with avatar, name, demand vs capacity bar, and stats. Click any row to toggle that user's filter. Excluded rows are dimmed. The filter state is shared between both views.
  In Per Sprint mode, each user's capacity is an even split of the sprint total. In Per User mode, each user has their own individual capacity.

Issue Table

When a sprint is expanded, you see its issues in a table. The columns shown are the ones you selected in Display Columns (Settings). Every row has:

• A checkbox for selecting the issue (used for multi-select drag)
• A lock icon to pin the issue in place (it won't be moved by Auto-Level or dragged accidentally)
• The issue key (e.g., PROJ-42) — if this issue has a dependency conflict, a warning icon appears next to the key
• Your configured columns (Summary, Assignee, Points, Status, etc.). In Time mode, the "Story Points" column header automatically changes to "Time (hrs)" or "Time (days)" to match the configured time unit.

Due dates in the past are highlighted in red. Assignees show a colored avatar chip.

Column Sorting

Click any column header to sort the issues in that sprint. Click again to reverse the order, and a third time to clear the sort. A small arrow (↑/↓) shows which column is sorted and in which direction.

Sorting is per-sprint (each sprint sorts independently) and resets when you reload. It is not saved. If you manually reorder an issue (by dragging within the sprint), the sort is cleared.

How Capacity Works

Each sprint has a capacity value that represents how much work it can hold. A dropdown in the sprint header controls where this number comes from:

Option	Per Sprint mode	Per User mode
Settings default	Uses the Capacity Limit from Settings	Each assignee gets the per-user limit from Settings; sprint total = users × limit
Team / Capacity settings	Uses calculated capacity from team config	Each person's capacity is calculated from the Team & Capacity tab & sprint dates
Custom / Custom for sprint	You type a sprint total	You type a per-user value; sprint total = users × your value

Settings default

The sprint uses the Capacity Limit from Settings. In Per Sprint mode, this is the whole sprint's capacity. In Per User mode, each assignee gets the per-user limit, and the sprint total is the sum (displayed as "N × limit = total").

Team / Capacity settings

In Per User mode (labeled "Capacity settings"), capacity is calculated from team members configured on the Team & Capacity tab:

• Points Mode — for each week that overlaps the sprint: sum(member's weekly points × utilization% × overlap fraction). Overlap fraction accounts for weeks that start or end mid-sprint. Holidays and time-off days reduce the overlap fraction proportionally.
• Time Mode — for each week that overlaps the sprint: sum(member's weekly hours × utilization%), minus hours for holidays and time off. Days = hours ÷ 8 (8-hour workday).

The display shows a formula: assignees × per-user capacity = sprint total.

In Per Sprint mode (labeled "Team"), capacity is calculated from team config. If no team members are configured, the option is greyed out.

Custom / Custom for sprint

Opens an inline number editor where you type a capacity value. In Per Sprint mode, this is the sprint total. In Per User mode, you enter a per-user value and the sprint total is calculated as users × your value (displayed as "N × value = total").

Capacity Display

The sprint header shows capacity remaining — the total capacity minus completed work. This lets you compare remaining demand against remaining capacity at a glance. If remaining demand exceeds capacity remaining, the demand stat turns red and an "over by X" indicator appears. When no issues are done yet, capacity remaining equals the full sprint capacity.

9. Sprint Management

You manage the sprint lifecycle directly from each sprint card's action buttons.

Creating a Sprint

Click + Create Sprint below the sprint list. The new sprint gets dates that follow on from the last sprint, using the Sprint Length you configured (2, 3, or 4 weeks).

Starting a Sprint

Click Start on a future sprint to make it active. If you already have an active sprint, a warning asks you to confirm that you want two sprints running at the same time.

Completing a Sprint

Click Complete on an active sprint. If there are unfinished issues, a dialog lets you choose where to move them — to another sprint or back to the backlog. When the sprint completes, its velocity data is automatically captured for the Velocity section.

Deleting a Sprint

Click the delete button and confirm. The sprint is removed and its issues move to the backlog.

Editing the Goal

Open the Sprint Details panel, then click the goal text. Type your changes and press Enter or click away to save.

Syncing Issue Dates

You can align issue dates with sprint boundaries:

• Sync Dates (per sprint) — sets every issue's start date and due date to match that sprint's start and end dates
• Sync All — does the same for every sprint at once
• Remove All — clears start and due dates from all issues in all sprints

This is useful for features like the Team & Capacity chart and What-If (Project view) that rely on issue dates.

10. Drag and Drop

Moving Issues Between Sprints

Drag any issue row from one sprint and drop it onto another sprint card. The issue is moved in Jira immediately. You can also drag issues to the backlog at the bottom.

Moving Multiple Issues

Check the boxes next to several issues, then drag any one of them. All selected issues move together. A badge shows how many you're moving (e.g., "5 issues"). A bar above the sprint list shows your selection count with a Clear selection button.

Reordering Within a Sprint

Drag an issue up or down within the same sprint to change its position. A blue line shows where it will land. This custom order is saved and persists across sessions.

Reordering is disabled while a column sort is active. If you reorder an issue, the sort clears.

Auto-Scroll

While dragging, move your cursor near the top or bottom edge of the screen. The page scrolls automatically so you can reach sprints that aren't currently visible.

Locked Issues

Click the lock icon on an issue to prevent it from being dragged. Locked issues also stay in place during Auto-Level.

11. Auto-Level

Auto-Level is a planning tool that redistributes issues across sprints so that no sprint exceeds its capacity. It uses each sprint's capacity setting: Manual numbers if set, Team-calculated values if selected (Per User mode), or the Settings default otherwise. It respects dependencies (blockers always go in earlier sprints) and leaves locked issues and sprints alone. Everything happens as a preview first — nothing is saved to Jira until you explicitly accept.

How to Use It

1. Click the Auto-Level button in the Sprints toolbar. A dropdown appears with strategy options: Priority, Size, Due Date, Balanced, Velocity, and Compare All.
2. Click a strategy pill to start a session. The sprints rearrange in preview mode immediately. Each moved issue shows a purple badge indicating where it came from.
3. Review the results. You can:
   • Click a different strategy pill to try another approach
   • Manually drag issues to fine-tune (these show orange badges)
   • Click Undo to reset and try again
4. When you're happy, click Accept to save all changes to Jira. Or click Exit to discard everything and leave the auto-level session.

Strategies

Strategy	How It Decides What Goes Where	Best For	Trade-off
Priority	Puts the highest-priority issues first, filling sprints front to back	Teams that want to ensure high-priority items ship first	Early sprints may contain a mix of large and small issues (size doesn't matter, only priority)
Size	Puts the smallest issues first, filling sprints front to back	Teams that want to maximize the number of items completed early	High-priority but large items may end up in later sprints
Due Date	Puts the soonest-due issues first, filling sprints front to back	Teams working against external deadlines	An issue with a tight deadline but low priority will be placed before a high-priority issue with no deadline
Balanced	Tries to spread work evenly. Places large issues first, picking the sprint where each one fits best based on remaining room, how much work each person already has in that sprint, and whether the sprint end date aligns with the issue's due date.	Teams that want predictable, consistent sprint loads	High-priority items may not all end up in the earliest sprints
Velocity	A toggle pill that uses historical efficiency to set sprint limits. When active, the other four strategy pills are disabled. See Using Velocity as Capacity below.	Teams with enough sprint history to have reliable velocity data	If recent velocity was unusually low (holiday sprint), the algorithm becomes overly conservative

All strategies respect dependencies: if issue A blocks issue B, then A is always placed in an earlier (or same) sprint as B. If circular dependencies exist, they are detected and flagged so you know to resolve them.

What Gets Moved

• All non-done issues from unlocked sprints are picked up and redistributed
• Done, closed, and resolved issues stay where they are — and their completed work is subtracted from sprint capacity so remaining room is calculated accurately
• Subtasks are excluded from moves (they follow their parent issue)
• Locked issues stay in place
• Issues in locked sprints are not touched
• If an issue is larger than any sprint's capacity (oversized), it is placed in a dedicated overflow sprint to keep other sprints balanced

New Sprints

If the existing sprints don't have enough room, Auto-Level creates new ones (up to 10). New sprints get dates that follow on from the last sprint using your Sprint Length setting, and their capacity defaults to the average of your existing sprints.

Per-User Mode

When Capacity Mode is set to Per User in Settings, Auto-Level tracks each person's workload per sprint individually. If someone is overloaded in a sprint, their excess issues are moved to a sprint where they have room. This produces a different result from Per Sprint mode: an issue might stay in Sprint 1 in Per Sprint mode (team total is fine) but get moved to Sprint 2 in Per User mode (because its assignee is overloaded).

Using Velocity as Capacity

If you have velocity data (from completed sprints), the Velocity toggle pill appears in the strategy row. Click it to activate velocity-based capacity. This tells Auto-Level to calculate sprint limits based on each team member's historical efficiency against their real available capacity (from the Team & Capacity tab), rather than using the configured limit or raw team availability.

When enabled:

• Per-user efficiency — for each team member, the app calculates how much of their available capacity they actually completed on average across recent sprints (capped at 100%). New members with no history use the team average.
• Adjusted sprint limits — each future sprint's limit is the sum of (member's future capacity × member's efficiency) for all active members. This gives a realistic prediction of actual output.
• Strategy pills disabled — the Priority, Size, Due Date, and Balanced pills are disabled because velocity-based distribution uses the efficiency-adjusted capacity directly.

For best results, configure your team on the Team & Capacity tab first. If no team capacity data is available, the feature falls back to the original behavior (flat historical average velocity).

Compare All

Click Compare All to run all four strategies at once and see a side-by-side comparison. The Delivery Forecast panel appears showing:

• KPI cards for each strategy — which sprint delivery lands in, the estimated date, and how many sprints are overloaded. The best strategy is highlighted.
• Probability curves — Monte Carlo simulations for each strategy overlaid on one chart. You can see which strategy gives the highest probability of on-target delivery. Click legend items to show or hide individual curves.

Strategy colors: Priority (blue), Size (orange), Due Date (green), Balanced (purple), Original baseline (gray).

12. Velocity Tracking

Below the sprint cards, the Velocity section shows how your team has performed in past sprints. This data feeds into capacity calculations and the "Use velocity as capacity" option in Auto-Level.

KPI Tiles

Five summary tiles across the top:

• Avg Velocity — mean(completed work per sprint) across the lookback window. Units match your Estimation Mode (points or hours/days).
• Expected — projected output for the next sprint based on recent velocity trend (weighted toward more recent sprints)
• Per Week — avg velocity ÷ sprint length in weeks
• Efficiency — mean(completed ÷ planned) across recent sprints — what percentage of planned work the team actually delivers. When Capacity tab data is available, a separate efficiency-vs-capacity metric tracks completed work against real available hours.
• Completion — mean(completed ÷ committed) — what percentage of committed work gets finished each sprint. Shows trend direction (improving, stable, declining) by comparing recent vs older sprints.

Filtering by User

A row of user chips lets you see velocity for specific team members. Click a name to filter; click "All" to show the whole team. You can select multiple people.

Velocity History

A table showing each completed sprint: name, length, capacity, completed work, per-week rate, and efficiency. The best-performing and worst-performing sprints are highlighted.

Click any row to expand it and see individual issues from that sprint — which were completed, which were left incomplete, and which were added or removed mid-sprint.

Building Your Velocity Data

Velocity data accumulates automatically each time you complete a sprint. If you're starting fresh or want to backfill history, use these buttons:

• Import from Completed Sprints — scans all previously completed sprints on your board and imports their data
• Reload — refreshes the velocity data
• Clear — removes all stored velocity data (asks for confirmation first)

13. What-If Analysis

The What-If tab lets you explore how changes in team performance, scope, and estimates would affect your delivery timeline. It combines adjustable sliders with the Delivery Forecast and the Demand vs Capacity chart to give immediate visual feedback. A Sprint / Project toggle at the top switches between two views.

Aspect	Sprint view	Project view
Data source	Sprints from board	Issues with due dates (from JQL)
Time buckets	Sprints	Weeks (Monday boundaries)
Requires	Sprint Mode ON	Issues with due dates
Capacity	Per-sprint capacity	Weekly capacity (holiday and time-off aware)
Chart labels	Sprint names	Week dates (e.g., "Mar 10")

Both views share the same sliders, Monte Carlo simulation, AI analysis, and KPI cards. The only difference is the time buckets used.

Sliders

Four sliders adjust different aspects of the project simulation. Each ranges from -50% to +50%:

Velocity (Slower / Faster)

Scales each team member's throughput. At +20%, every team member delivers 20% more per sprint. At -30%, everyone delivers 30% less. Models the team working faster or slower than historical averages.

Capacity (Less / More)

Scales each team member's available capacity. Simulates adding or losing resources — for example, a team member going on extended leave (less) or a new hire ramping up (more).

Issue Estimation (Smaller / Larger)

Scales the estimated size of each issue. Moving right simulates issues being larger than estimated (common in early-stage projects). Moving left simulates estimates being conservative.

Scope (Less / More)

Scales the total remaining work. Moving right simulates scope additions beyond the current backlog. Moving left simulates scope cuts.

How Sliders Compound

Velocity and Capacity compound together on the supply side. Issue Estimation and Scope compound together on the demand side. Moving Velocity +10% and Capacity +10% produces a 21% increase in effective throughput (1.10 × 1.10 = 1.21). Similarly, Issue Estimation +20% and Scope +10% produces 32% more demand.

As you adjust the sliders, both the Delivery Forecast stat card and the Demand vs Capacity chart update in real time, using the same underlying simulation.

Presets (Simulation Mode Only)

In Simulation mode, each slider has per-variable preset buttons that set the uncertainty range for that variable:

• Optimistic — narrow range skewed toward favorable outcomes (e.g., Velocity −5% to +20%)
• Realistic — moderate range reflecting typical variance (e.g., Velocity −15% to +10%)
• Conservative — wide range skewed toward unfavorable outcomes (e.g., Velocity −25% to +5%)

Presets are per-variable — you can set Velocity to Optimistic while keeping Scope at Conservative. In What-If mode (fixed sliders, not simulation), there are no presets — you set each slider to a specific value.

KPI Cards

• Target Sprint/Week — the planned delivery point (defaults to last sprint/week with work; changeable via dropdown)
• Finish on Time? — Yes/No based on whether projected delivery is at or before target
• Projected Delivery — the sprint/week where all work is expected to complete
• Sprints/Weeks Over Capacity — count of periods where demand exceeds capacity
• Overflow — remaining work past the last planned period (in points or hours)

AI Risk Analysis

An AI chat panel lets you describe scenarios in natural language (e.g., "What if we lose a developer for 2 sprints?"). Requires an AI API key in Settings. The AI returns slider recommendations with an Apply button, impact assessment, and prioritized recommendations.

14. Demand vs Capacity Chart

The Demand vs Capacity chart shows how your team's workload compares to their capacity across each sprint (or week, if Sprint Mode is off). Each sprint appears as a pair of stacked bars — one for demand, one for capacity — so you can see at a glance where the team is overloaded and who is driving it. This chart appears on the What-If tab and updates in real time as you adjust sliders.

Reading the Chart

Each sprint has two stacked bars side by side:

Capacity Bar (left)

Shows each team member's available capacity for that sprint, stacked by person. Each segment's height represents that member's net capacity after accounting for their utilization rate, holidays, and PTO. The total bar height is the sprint's total team capacity.

Demand Bar (right)

Shows each team member's assigned work for that sprint, stacked by person in the same order and color. Unassigned issues appear as a grey segment at the top. The total bar height is the sprint's total demand including any overflow carried from the previous sprint.

Colors

Each team member is assigned a consistent color across both bars. When a member's demand segment is taller than their capacity segment, their portion is highlighted to flag the imbalance.

Overflow Cascade

When a sprint's total demand exceeds its total capacity, the excess work carries forward to the next sprint. A dashed line separates planned demand from overflow. Sprints receiving overflow show the carried work as a hatched segment at the base of their demand bar.

What the Chart Tells You

Pattern	What It Means	What to Do
Balanced sprint	Demand and capacity bars are roughly equal height. Work is evenly distributed across team members.	No action needed — the sprint is healthy.
Overloaded sprint	Demand bar is taller than capacity bar. Overflow will cascade to the next sprint, pushing later work out.	Move issues to later sprints, or increase capacity (add team members, reduce PTO).
Individual bottleneck	One team member's demand segment is much larger than their capacity segment, even though the sprint's total demand may be within total capacity.	Reassign work from the overloaded member to someone with spare capacity.
Idle capacity	A member's capacity segment is visible but their demand segment is small or absent.	Assign more work to that person, or consider reallocating them to another project.

Projected Completion Marker

Two vertical markers on the chart indicate key milestones:

• T (purple) — Target: the planned delivery deadline
• P (green or red) — Projected delivery: where all work is expected to complete. Green when on or before target, red when late.

The projected completion marker shows the sprint where all remaining work, including cascaded overflow, is finally absorbed. This matches the date shown in the Delivery Forecast stat card.

15. Monte Carlo Simulation

Monte Carlo simulation replaces the fixed What-If sliders with randomized ranges to produce a probability distribution of completion dates. Instead of asking "what if velocity is +10%?", it asks "what is the range of likely outcomes given realistic uncertainty?"

How It Works

1. For each of the four variables (Velocity, Capacity, Issue Estimation, Scope), you set a low and high value representing the plausible range using dual-dot sliders.
2. The system runs 2,000 scenarios (Sprint view) or 5,000 scenarios (Project view). In each scenario, a global trend is drawn for each variable, then each team member receives a blend of 50% global trend and 50% per-user noise within the configured ranges. One scenario might have Alice performing at +15% velocity while Bob performs at −5% — reflecting real-world variation where team members don't all have identical sprints, but correlated trends (like holiday weeks) still affect everyone.
3. Each scenario runs the full per-sprint, per-user stepped simulation with its randomized inputs and records the projected completion date.
4. The results are assembled into a probability distribution.

Dual-Dot Sliders

Each variable has a range slider with two dots:

• Red dot (left) — the pessimistic end of the range
• Green dot (right) — the optimistic end of the range

For each trial, the simulator picks a random value between the red and green dots. Wider ranges model more uncertainty; tighter ranges model a more predictable project.

Reading the Results

P50 (Median)

The date by which you have a 50% chance of finishing. Half of the simulated scenarios finished before this date, half after. Use this as the "most likely" outcome.

P85 (Conservative)

The date by which you have an 85% chance of finishing. This is the standard planning target for teams that want high confidence in their commitments. When giving dates to stakeholders, P85 is the safest choice.

Distribution Curve (S-Curve)

The spread of possible outcomes plotted as a cumulative probability curve. Key markers on the chart:

• 80% confidence marker (green dashed) — the point with 80% probability of completion
• Target marker (purple dashed) — the planned delivery date, with on-target probability percentage

A narrow curve means the project timeline is predictable regardless of individual variation. A wide curve means small changes in team performance produce large swings in the delivery date — a signal that the plan is fragile and needs attention.

Why Per-User Randomization Matters

Traditional Monte Carlo applies the same random factor to the entire team — everyone is fast together or slow together. Project Commander uses a blended per-user randomization model: each iteration draws a global trend (50% weight) that captures team-wide factors like holiday weeks or infrastructure outages, then adds per-user noise (50% weight) that captures individual variation. Alice might have a productive sprint while Bob is blocked by a complex issue, but both are affected by the same team-wide trend.

This blended approach produces wider, more realistic distributions than pure team-level randomization while avoiding the over-optimism of fully independent models. A team of 5 where each member varies semi-independently has far more possible outcomes than a team where everyone moves in lockstep.

When to Use Simulation vs What-If

Use Case	Tool	Why
Explore a specific scenario ("What if we lose a team member?")	What-If sliders	The sliders give you a single deterministic answer for a specific set of assumptions.
Understand the range of likely outcomes for planning	Monte Carlo simulation	The probability distribution tells you not just when you might finish, but how confident you can be in that date.
Set a commitment date for stakeholders	Monte Carlo P85	The P85 date gives you 85% confidence — enough margin for most stakeholder commitments.
Compare different planning strategies	Compare All + simulation curves	Overlay Monte Carlo distributions from different Auto-Level strategies to see which gives the tightest, most favorable distribution.

16. Team & Capacity Tab

The Team & Capacity tab combines demand analysis and team configuration in one place. The Demand vs. Capacity chart appears first, followed by team configuration below.

• Demand vs. Capacity Chart — shows demand and capacity traces over time. Where demand rises above capacity, you have a delivery risk. Filter by team member or time period.
• Team Members — configure each member's hours per sprint, utilization %, and view their demand and status
• Time Off — individual time off entries that reduce net capacity
• Company Holidays — shared holidays that affect the whole team

Three Sections

The tab has three collapsible sections. Click any section header to expand or collapse it:

1. Team Members — your team roster and workload status
2. Time Off — PTO calendar for individual team members
3. Company Holidays — company-wide days off

Period Selector

A period bar at the top lets you choose the time range you're looking at: Weekly, Biweekly, Monthly, Quarterly, or Yearly. Arrow buttons navigate forward and back. All the numbers in the Team Members table (net capacity, demand, issue count) adjust to show values for the selected period.

Team Members

A table showing each team member with these columns:

Column	What It Shows
Name	Team member name with a colored avatar. A view time off link opens a modal showing all of that person's time off (see below).
Hrs/Wk or Pts/Wk	Capacity per week (editable). In Time Mode shows hours per week; in Points Mode shows points per week. Edit to set all weeks in the current period to that value.
Total	Total capacity for the selected period — the sum of all weekly values
Util %	Utilization percentage (editable). Adjusts how much of a member's capacity is available for project work. Defaults to 100%. Persists to team member configuration.
Time Off	Total hours deducted for holidays and PTO in the period. Click the toggle to expand a detail row showing each holiday and PTO entry with dates and hours.
Net Hrs / Net Pts	Net capacity after deductions. Calculated as Total capacity minus holiday deductions minus PTO hours. In Time Mode shows Net Hrs (or Net Days); in Points Mode shows Net Pts. This is the number used for workload status.
Demand	How much work is assigned to them in the period
Issues	Number of issues assigned, with expandable dropdown showing issue keys and summaries
Status	A color-coded badge comparing demand against net capacity (after deductions)

You can select multiple team members using the checkboxes. The Cap/Wk column shows "varies" if weeks in the period have different values.

Weekly Capacity Model

Capacity is stored as explicit per-week values. Each team member has a capacity value for each ISO week (Monday–Sunday). Weeks with no value set default to zero.

• Weekly view: Shows and edits the value for that specific week.
• Monthly/Quarterly/Yearly view: Shows the per-week value if all weeks are the same, or "varies" if they differ. Editing sets all weeks in the period to the entered value.

This model gives you full control — reduce capacity for holiday weeks, ramp new members up gradually, or set different values for different sprints. All downstream calculations (sprint capacity, demand vs capacity, risk) resolve to weekly granularity.

If you have existing team data from before the weekly model, a migration banner appears with a "Populate weeks" button that fills the selected period from your previous rates.

How Sprint Capacity Is Calculated

When the Delivery Forecast or Sprints tab needs a capacity number for a sprint, the system combines each team member's weekly capacity map with the sprint's date range:

Points Mode:

Sprint capacity = Σ(member) [ Σ(week overlapping sprint) [ weeklyPoints × utilization% × overlapFraction ] ]

Time Mode:

Sprint capacity = Σ(member) [ Σ(week overlapping sprint) [ weeklyHours × utilization% ] − holidayHours − ptoHours ]

Where:

• weeklyPoints / weeklyHours — the member's configured capacity for that specific ISO week (from the Team panel)
• utilization% — the member's utilization percentage for that week (defaults to 100%)
• overlapFraction — what fraction of the week falls within the sprint. A sprint starting on Wednesday only gets 3/5 of that week's capacity.
• holidayHours — company holidays (recurring or specific dates) deducted from business days
• ptoHours — member-specific time off entries, summed for the sprint period

Inactive team members contribute zero capacity. This calculation is used by the Delivery Forecast (Team Capacity method), Auto-Level, and the Demand vs Capacity chart when "Team capacity" is selected as the capacity source.

Status Badges

Each team member gets a color-coded status based on how their assigned work (demand) compares to their net capacity — capacity after holiday and PTO deductions:

Status	When It Appears	Color
OVERLOADED	Demand is more than 115% of capacity	Red
OPTIMAL	Demand is 90–115% of capacity	Green
AVAILABLE	Demand is 60–90% of capacity	Yellow
UNDERLOADED	Demand is less than 60% of capacity	Gray

Time Off

A calendar view for managing PTO. Click a date to mark a single day off. Use Ctrl+click to toggle individual days on and off. Use Shift+click to select a range of dates.

Time off and company holidays are automatically deducted from each member's capacity. The deductions appear in the Time Off column of the Team Members table. Click the toggle arrow to expand a detail row listing each holiday and PTO entry with its date and hours deducted. The resulting Net column shows capacity after all deductions.

View All Time Off

Click the view time off link next to any team member's name to open a modal showing all of their time off across all time periods. The modal includes:

• Summary — total PTO days, holidays, and combined hours at a glance
• Grouped by month — entries are organized by month with subtotals for each
• PTO entries — individual time off with date, reason, and hours. Click × to remove an entry.
• Company holidays — shown with a distinctive icon on a yellow background so they're easy to distinguish from PTO
• Add Time Off — a form at the bottom lets you add new time off directly from the modal by picking a date, hours, and optional reason

Company Holidays

Add company-wide holidays by entering a date and name. Check the Recurring box to have the holiday repeat every year automatically. Holidays reduce available capacity for all team members.

Demand vs Capacity Chart

The chart shows daily capacity (green) and daily demand (blue) side by side so you can see whether your team can keep up with the work. Click legend items to toggle additional traces like cumulative totals, scope, and completion percentage. Red-shaded areas highlight overload zones where demand exceeds capacity.

Summary Stats

Above the chart, summary stats show cumulative capacity and cumulative demand for the selected period, and whether demand exceeds capacity (shown in red as “Over by”).

Resource Breakdown

Below the chart, a collapsible Resource Breakdown table lists each team member with their issue count, demand, load percentage, and status badge (Available, Loaded, or Overloaded).

Chart Options

Below the chart, controls let you customize the analysis:

• Demand source: Controls how each issue's work is positioned on the timeline:
  • Sprint Dates — places each issue's demand within its sprint's start/end dates. Only available when Sprint Mode is on.
  • Spread — divides each issue's demand equally across all weeks from its start date to its due date. An 8-point issue spanning 4 weeks adds 2 points per week. Issues with only a due date place all demand on that date.
  • Due Date — places 100% of each issue's demand on its due date. Produces sharp spikes showing when work is actually due.
• Capacity source: Controls how team capacity is calculated for the chart:
  • Settings default — uses the capacity limit from Settings, spread evenly across the timeline.
  • Team capacity — uses each member's weekly capacity from the Team panel (hours or points per week × utilization%), so capacity varies week to week based on team configuration.
  • Effective capacity — team capacity × historical delivery efficiency%. Only shown when velocity data is available.
• Include Backlog: Include non-sprint issues in demand
• Assignee filter: Colored chips above the chart to filter to specific team members
• Period selector: All Time, Weekly, Biweekly, Monthly, Quarterly, or Yearly

17. Scope Tab

The Scope tab shows how much work has been added over time and how much has been completed, all on one timeline chart. In Points Mode, values are in story points. In Time Mode, values are in hours or days.

The Chart

Two lines tell the story:

• Scope (blue) — cumulative work added over time. As new issues are created or estimates increase, this line goes up.
• Burndown (green) — cumulative work completed over time. This line goes up (not down) as more work is finished. The line stops at the last completed issue rather than extending flat into the future. The gap between the two lines is your remaining work.
• Burndown Forecast (red dashed) — projected completion curve extending into future periods. Appears by default using the Priority strategy.
• Scope Growth (purple dashed) — projected scope line showing where scope will be if growth continues at the historical rate. Only appears when scope growth is enabled.

The chart legend is interactive — click any legend item to show or hide its trace. Hidden items appear dimmed with a strikethrough label.

Filtering by User

A row of colored user chips appears above the chart (always visible when there are multiple assignees). Click a name to filter the burndown line to just that person's completed work. The scope line always shows the total scope. Click “All” or clear selections to reset.

Chart Controls

Inline controls appear between the user chips and the chart:

• Sprint Markers — toggle sprint boundary lines on the chart: solid lines for start dates, dashed lines for end dates. Only shown when Sprint Mode is on.
• Include Completed Sprints — include or exclude closed sprints from the markers. Only shown when Sprint Mode is on.
• Burndown Forecast checkbox — toggle the forecast on or off (on by default).
• Strategy dropdown — choose a forecast strategy. The forecast burns down remaining work at the team's weekly throughput rate, but the strategy determines the order in which issues are projected to complete:
  • Priority (default) — highest-priority issues complete first. The curve drops fastest where high-priority work is concentrated.
  • Size — smallest issues complete first. Many small issues burn down quickly, then larger ones cause a slower tail.
  • Due Date — issues with the earliest due dates complete first.
  • Balanced — spreads work evenly, placing large issues first into periods with the most room.
  • Velocity — uses each team member's historical efficiency-adjusted throughput rate instead of the global average.
  • Compare All — overlays all strategies on the chart simultaneously so you can see how ordering assumptions affect the projected completion date.
  All strategies use the same total remaining work and the same throughput rate. If scope growth is enabled, new work is added each period until the forecast reaches zero.
• Lookback — choose how many past periods (sprints or weeks) to include in velocity calculations.

Period Selector

Choose how the timeline is grouped: Weekly, Biweekly, Monthly, or Quarterly. Arrow buttons navigate between periods.

Stat Cards and Breakdown

Below the chart, stat cards show Total Scope, Completed Work, Remaining Work, % Complete, and issue counts. A breakdown table lists individual issues grouped by the selected period.

Delivery Forecast (Scope Tab)

The Scope tab has its own Delivery Forecast stat card with the same controls as the Dashboard: Delivery Projection Method dropdown and Scope Growth Method checkbox + dropdown. The projection method and scope growth settings are shared — changing them on one tab updates the other.

18. Alerts Tab

The Alerts tab scans your issues for common problems and analyzes dependency relationships. A badge on the tab shows the total number of alerts found.

Alert Categories

Issues are grouped into six collapsible sections. Click a category header to expand or collapse it:

Category	What It Catches
Done with Remaining Work	Issue is marked Done but still has time remaining on it
Overdue	Issue is not Done and its due date has passed
Dependency Conflicts	Issue is blocked by something that finishes after it should start. Also detects circular dependencies.
Child After Parent	A subtask is due after its parent task
Missing Dates	Issue in an active or future sprint has no start date or no due date
Missing Estimates	Issue in an active or future sprint has no estimate. In Points Mode this checks for story points; in Time Mode this checks for original estimate.

Dependency Analysis

Below the alert categories, a collapsible Dependency Analysis section gives you the full picture of blocking relationships:

• Summary — total dependencies, circular dependencies, cross-sprint conflicts, root issues (things that block others but aren't blocked themselves), leaf issues (things that are blocked but don't block anything), and the longest dependency chain
• Dependency list — all blocking relationships, with cross-sprint conflicts highlighted in color
• Conflicts filter — a "Show conflicts only" checkbox to focus on cross-sprint violations
• Root and leaf issues — the top 10 root and leaf issues for quick identification

19. Epics Tab

The Epics tab gives you a bird's-eye view of your project organized by epic. It groups child issues under their parent epics and shows progress, scope changes, and status — all in a single sortable table. Works in both Sprint Mode and non-Sprint Mode.

Filtering and Sorting

A search box at the top filters epics by name or key. Dropdowns let you filter by status (All Epics, On Track, At Risk, Behind, To Do, Done, Overdue) and by owner. Click any column header to sort.

Epic Progress Table

Each row shows one epic with:

• Epic — name and Jira key
• Assignee — the most frequent assignee across the epic's child issues
• Progress — a color-coded progress bar with percentage: green (≥ 60%), amber (30–59%), red (< 30%)
• Points / Hours — done work out of total (e.g., "11 of 14 pts")
• Start Date — earliest start date among child issues
• Due Date — latest due date among child issues
• Status — derived automatically (see below)
• Scope Change — how much scope has changed since baseline

Click any epic row to expand it and see all child issues with their individual status, assignee, points, and sprint assignment.

How Status Is Derived

Status	Condition
Done	100% complete or parent issue is in a Done status
Overdue	Due date is in the past and not Done
On Track	≥ 60% complete
At Risk	30–59% complete
Behind	1–29% complete
To Do	0% complete or no child issues

Filter Tabs

Three tabs filter the dependency list:

Tab	What It Shows
All	Every cross-epic dependency
Violations	The blocker epic is not on track AND blocked issues are not yet done — delivery is at risk
At Risk	The blocker epic is not on track but no unfinished blockers are blocking the dependent epic yet

Dependency Rows

Each row shows the blocker epic on the left, an arrow labeled "blocks" in the middle, and the blocked epic on the right. A status badge indicates the health of the relationship:

• Healthy (green) — blocker is done or on track
• At Risk (amber) — blocker is behind schedule
• Violation (red, dashed arrow) — blocker is behind and its unfinished work is actively blocking dependent issues

Each blocked epic shows how many issues are blocked and their total points or hours.

20. Estimation Modes

The Estimation Mode setting is the most important choice you make. It determines how work is measured, where capacity comes from, and what units every tab uses. Choose it once and the rest follows automatically.

Points Mode vs Time Mode

Aspect	Points Mode	Time Mode
What it measures	Story points	Remaining estimate (hours or days)
Where capacity comes from	Capacity Limit from Settings (Settings default), or team Points Per Sprint when Team/Capacity settings is selected	Capacity Limit from Settings (Settings default), or team hours/availability when Team/Capacity settings is selected
Jira field used	Story Points	Remaining Estimate
Display units	pts	hrs or days (based on Time Unit setting)
Time Unit setting	Hidden (not needed)	Visible — choose Hours or Days
Progress indicator	Points (done / total)	Estimate (remaining / original) or Work Ratio

How Each Tab Behaves

Dashboard Tab

All health cards, workload bars, and scope values use story points in Points Mode, or hours/days in Time Mode. The unit label adjusts automatically (pts, hrs, or days).

Sprints Tab

• Points Mode: Each sprint's demand is the sum of story points. The capacity warning and progress bar work in points. When Auto is selected, capacity is calculated from team Points Per Sprint.
• Time Mode: Demand is the sum of remaining estimates, shown in hours or days. When Auto is selected, capacity is calculated from team members' weekly capacity values.

Team & Capacity Tab

• Points Mode: Total capacity shows the sum of each member's weekly points values for the period. Demand shows their assigned story points.
• Time Mode: Total capacity shows the sum of each member's weekly hours values for the period. Demand shows their assigned remaining estimate.

Scope Tab

The scope and burndown chart shows story points in Points Mode, or hours/days in Time Mode.

Alerts Tab

The "Missing Estimates" alert checks for story points in Points Mode, or original estimate in Time Mode.

What-If (Sprint / Project view)

The What-If sliders, cascade chart, and Monte Carlo simulation all work in story points (Points Mode) or hours/days (Time Mode).

What Happens When You Switch

Switching Estimation Mode automatically adjusts related settings:

• Switch to Points → uses Jira's Story Points field, Progress Indicator becomes Points
• Switch to Time → uses Jira's Remaining Estimate field, Progress Indicator becomes Estimate

You only need to choose your Estimation Mode — the Jira field and Progress Indicator follow automatically.

Time Unit Conversion

Jira stores time in seconds internally. Project Commander uses an 8-hour workday for conversion:

• 16 hours = 2 days
• 40 hours = 5 days (one work week)

When Time Unit is set to Days, all time values throughout the app are shown in workdays instead of hours.

Setting Up Time Mode

1. Open Settings and set Estimation Mode to Time
2. Go to the Capacity tab
3. Add your team members and set their weekly capacity (Hrs/Wk or Pts/Wk)
4. Add any Company Holidays (for reference)
5. Use the Time Off calendar to track PTO, then adjust weekly capacity as needed
6. Sprint capacity will now be automatically calculated from your team's weekly values

21. Dependencies

Project Commander detects blocking relationships from Jira's "blocks" and "is blocked by" issue links. Dependencies affect multiple features across the app.

Where Dependencies Appear

Sprints Tab

Issues with dependency conflicts show a warning icon (⚠) next to their key in the issue table. The icon has a tooltip describing the conflict (e.g., "Blocked by PROJ-45 which ends after this issue starts").

Alerts Tab

The Dependency Conflicts alert category lists all issues where a blocker finishes after the blocked issue should start. The Dependency Analysis section provides the full dependency graph with summary stats, edge list, root/leaf issues, and a conflicts-only filter.

Dependency Map Modal

Click the Dependencies button in the action header to open a modal with three tabs:

• All — every blocking relationship across all sprints
• Cross-Sprint — only dependencies that span different sprints
• Violations — only dependencies where the blocker is in a later sprint than the issue it blocks

Each dependency shows the blocker and blocked issue with their sprint name, sprint state badge (active/future), and completion status. Violation rows are marked with a warning icon.

Auto-Level

Auto-Level always respects dependencies. A blocking issue is placed in an earlier (or same) sprint as the issues it blocks. If circular dependencies exist, they are detected and reported, and the affected issues are still placed using the chosen strategy.

22. Settings Reference

Click the Settings gear icon (⚙) in the tab bar to open the configuration panel. Settings are saved per Jira site and shared across all users. This section provides a comprehensive reference for every setting and how it affects the app.

All Settings

Setting	Type	Default	Visible When
JQL Filter	Text area	Empty	Always
Epics	Checkbox	On	Always
Sprint Mode	Checkbox	On	Always
Board	Search/select with auto-detect	Empty	Sprint Mode ON
Include Backlog	Checkbox	On	Sprint Mode ON + Board selected
Capacity Mode	Radio: Per Sprint / Per User	Per Sprint	Sprint Mode ON
Progress Indicator	Dropdown	Points (Points Mode) / Estimate (Time Mode)	Sprint Mode ON
Capacity Limit	Number (min: 1)	40 (sprint) / 20 (user)	Sprint Mode ON
Sprint Length	Dropdown: 1/2/3/4 weeks	2 weeks	Sprint Mode ON
Velocity Lookback	Dropdown: 3 / 5 / 8 / 10 sprints	Last 5 sprints	Sprint Mode ON (also settable from Dashboard and What-If)
Estimation Mode	Radio: Points / Time	Points	Always
Time Unit	Dropdown: Hours / Days	Hours	Estimation Mode = Time
Display Columns	Multi-select with search	Key, Summary, Assignee, Story Points	Always
AI Features	Provider dropdown + API key + Model selector	Empty	Always
Read-only Mode	Checkbox	Off	Always (standalone app)
Enable Work Leveling	Checkbox	On	CSV mode only

Estimation Mode — The Master Switch

Estimation Mode is the most important setting. It controls which Jira field is read, what units are shown everywhere, and how capacity is sourced. Every other setting cascades from this choice.

Full cascade when you switch from Points to Time:

• Sprint headers: Labels change from "pts" to "hrs" (or "days"). Numbers change entirely — a sprint showing "Demand: 40 pts | Capacity: 40 pts" might now show "Demand: 320 hrs | Capacity: 320 hrs". A sprint that was green in points might turn red in hours if your team's hour-based capacity doesn't match your point-based limit.
• Issue rows: The column header changes from "Story Points" to "Time (hrs)" or "Time (days)". The Remaining Estimate field drives the values instead of Story Points.
• Dashboard: Delivery Forecast now compares remaining hours against team availability in hours. The answer can flip from "On target" to "Not on target" because the capacity source changes.
• Auto-Level: Issue sizes are measured in hours instead of points, so the bin-packing algorithm fills sprints with hour-based limits.
• Alerts: "Missing estimates" checks a different Jira field per mode. You may see many more (or fewer) alerts.
• Dependencies and Risk Badges: No change — these use sprint order, not estimates.

Time Unit (Hours / Days)

Only appears when Estimation Mode is Time. A pure display conversion using an 8-hour workday. "Scope +96 hrs" becomes "Scope +12 days". The underlying data never changes — only the display.

Capacity Mode

Two choices: Per Sprint or Per User. Only shown when Sprint Mode is on.

• Per Sprint — one capacity number for the whole team per sprint. Demand is the sum of all issue estimates. The capacity bar turns red when total demand exceeds total capacity.
• Per User — individual capacity limits per team member per sprint. Each assignee gets their own capacity bar. The bar turns red when any single person is overloaded — even if the team total has room. This is more sensitive and catches workload imbalance.

Switching from Per Sprint to Per User changes the Auto-Level algorithm completely. Per Sprint mode distributes issues to fit sprint totals. Per User mode balances per-person workload, moving specific people's lowest-priority issues to sprints where that person has room.

Capacity Limit

The Settings default capacity when no other source is active. The label changes based on your Capacity Mode:

• Per Sprint: "Capacity limit per sprint" — default: 40
• Per User: "Capacity limit per user" — default: 20

This is the fallback — you can override it per sprint or per person directly in the Sprints tab. See Capacity Precedence Hierarchy below for the full override chain.

Sprint Mode

A checkbox (default: on). When turned off:

• Sprints tab disappears — no sprint management at all
• Sprint What-If disappears — only Project view remains
• Features that stop working: Auto-Level, Velocity tracking, Scope creep detection, Sprint risk badges, Create Sprint, Capacity Mode radio
• What still works: Dashboard cards (use issue due dates for forecasting), Demand vs Capacity analysis (uses issue date ranges), Alerts, Epics tab

Board

Select the Scrum board that contains your sprints. The app lists all Scrum boards on your Jira site — type to search, then click to select. If the app is opened from within a Jira board, the board is auto-detected. Required for the Sprints tab. Changing the board reloads all sprint data, velocity history, and team configuration (team settings are stored per board).

JQL Filter

Standard Jira JQL syntax. This query fetches the issues used across Dashboard, Scope, Alerts, Team & Capacity, and Epics tabs. The Sprints tab shows all issues from the board regardless of this filter.

Include Backlog

When enabled, unscheduled backlog issues from the board appear below the sprint list and are included in demand calculations across all views. The default is off — you see only committed/planned work. Turn it on when you want the full picture of everything that needs to get done.

Velocity Lookback

Controls how many past periods are included in velocity calculations and scope/burndown charts. This is a global setting that can be changed from four places: Settings, Dashboard, Sprints tab (Velocity section), and What-If. Range: 3–10, default 5. Fewer sprints means a more volatile average — a single good or bad sprint has more weight.

Sprint Length

Duration of new sprints created by Auto-Level: 1, 2, 3, or 4 weeks. Also affects velocity normalization — velocity is converted to "per week" by dividing by sprint length. If you change sprint length, consider adjusting your capacity limit proportionally.

Display Columns

Choose which columns appear in sprint issue tables. The default set is Key, Summary, Assignee, and Story Points. There are 20 standard columns available. You can also search for Jira custom fields by typing at least 2 characters in the search box. This only affects the issue table display — no impact on calculations.

AI Features

Configure an AI provider (Anthropic Claude, OpenAI ChatGPT, or Google Gemini) with an API key to enable AI-powered features: the AI Insights section on the Dashboard, and AI risk analysis on the What-If tab. You can optionally select a specific model from the provider's lineup.

Read-only Mode

When enabled, your Jira data is never modified. Drag-drop, sprint actions, and date syncing are disabled. You can still run Auto-Level preview (dry run) to see what it would do, but the "Accept" button is blocked. All viewing and analytics features still work normally.

Enable Work Leveling

Only visible in CSV mode (when data is loaded from a CSV file rather than Jira). When enabled, a Level Work banner appears at the top of the Scope and Team & Capacity tabs offering to redistribute tasks so no week exceeds capacity. Leveling shifts issue due dates to smooth out demand peaks. Disable this setting to hide the leveling banner.

Progress Indicator

Controls the small progress display in each sprint card header. Available options depend on Estimation Mode:

• Points (Done / Total) — available in Points Mode. Shows completed story points as a percentage of total.
• Estimate (Remaining / Original) — available in Time Mode. Shows how much remaining estimate has been worked off relative to original estimate.
• Work Ratio — available in Time Mode. Shows time spent as a percentage of total effort (spent + remaining).

Auto-Switching Cascade

Switching Estimation Mode automatically adjusts related settings to stay consistent:

When You Switch To	What Changes Automatically
Points	Uses Story Points field, Progress Indicator → Points
Time	Uses Remaining Estimate field, Progress Indicator → Estimate, Time Unit selector appears

Capacity Precedence Hierarchy

Capacity has multiple layers. The app resolves the effective capacity for each sprint using a priority order where the first match wins.

In Per Sprint Mode:

1. Per-sprint manual override — the user clicked the capacity number in the sprint header and typed a number. This exact number is used.
2. Per-sprint "Effective velocity" — the user selected effective velocity in the sprint header dropdown. The historical efficiency-adjusted capacity is used.
3. Per-sprint "Team capacity" — the user selected "Team capacity" in the sprint header dropdown. The calculated team capacity for this sprint is used (from team member hours/points, minus holidays and time off).
4. Settings default — nothing set for this sprint. The "Capacity limit per sprint" from Settings is used (default: 40).

In Per User Mode:

1. Per-user per-sprint override — the user clicked this person's capacity bar and typed a number. That number is used for this person in this sprint.
2. Per-sprint "Team capacity" per-member — the sprint is set to "Team capacity". Each member's calculated capacity from team config is used.
3. Per-sprint total override divided by assignee count — if a per-sprint manual number is set, it is divided evenly among assignees.
4. Settings default — nothing set. The "Capacity limit per user" from Settings is used (default: 20).

Where This Matters

• Sprint headers show the resolved effective capacity
• Auto-Level uses the resolved capacity as each sprint's "bin size"
• Dashboard uses resolved capacities to calculate over-limit counts and Delivery Forecast
• Team & Capacity uses the capacity source selected below the chart
• What-If simulation uses resolved capacities as the baseline for scenarios

Settings Dependency Diagram

How the major settings depend on and affect each other:

Setting	Determines / Gates / Feeds
Estimation Mode	Determines which Jira field is read (Story Points vs Remaining Estimate), unit labels everywhere, gates Time Unit dropdown and Progress Indicator options, feeds sprint headers, all Dashboard cards, Team & Capacity chart, What-If simulation inputs, Auto-Level issue sizing, Velocity units, Alerts field checks. Does NOT affect dependencies or risk badges.
Capacity Mode	Gates Capacity Limit field label, determines what "over capacity" means (team total vs individual person), determines which Auto-Level algorithm runs, determines sprint header layout (single bar vs per-person), gates Effective velocity option visibility.
Sprint Mode	Gates Sprints tab, Auto-Level, Velocity tracking, Scope creep detection, Sprint risk badges, Capacity Mode radio, Plan What-If checkbox.
Team Config	Feeds calculated capacity per sprint (when limit is "Team capacity"), Team & Capacity chart, Delivery Forecast card, What-If simulation baseline, Auto-Level bin sizes.
Velocity Lookback	Feeds velocity average, Delivery Forecast projected date, Effective velocity option in Auto-Level, Monte Carlo variance.
Sprint Length	Feeds velocity normalization (pts/week), new sprint date ranges from Auto-Level, Delivery Forecast weekly throughput.
Include Backlog	Feeds which issues are in scope for Dashboard demand, Demand vs Capacity analysis, Forecast remaining work, and Alerts issue set.
JQL Filter	Feeds Scope, Alerts, Team & Capacity, Epics tabs. NOT the Sprints tab or Auto-Level.
Display-only settings	Display Columns (issue table layout), Epics toggle (show/hide tab), Read-only Mode (disable writes), AI Provider/Key (enable AI chat). No calculation impact.

23. How Everything Connects

The Delivery Forecast, Scope Growth, What-If sliders, Demand vs Capacity chart, and Monte Carlo simulation all share the same underlying engine: a per-sprint, per-user stepped simulation that walks through future sprints consuming work against individual capacity.

The Shared Simulation Engine

Every forecasting feature in Project Commander runs the same simulation:

1. Walk through each future sprint (or week) in order.
2. For each sprint, calculate each team member's available capacity (hours or points, adjusted for utilization, holidays, and PTO).
3. Consume each member's assigned issues up to their capacity. Overflow remaining work to the next sprint.
4. Consume unassigned issues with whatever spare capacity remains.
5. Add scope growth to the unassigned pool each sprint.
6. Record the sprint where all work is absorbed — that is the projected completion.

One Source of Truth

All views are driven by the same model:

• The Delivery Forecast stat card runs the simulation once with current data to produce a single projected date.
• The What-If sliders scale the inputs and re-run the same simulation, updating the stat card and chart together.
• The Demand vs Capacity chart visualizes the per-sprint, per-user breakdown from the same simulation run.
• Scope Growth feeds into the simulation as additional unassigned demand per sprint.
• Monte Carlo runs the same simulation thousands of times with randomized per-user inputs to build a probability distribution.

If the stat card says May 30, the chart's completion marker points to the same sprint, and the Monte Carlo P50 clusters around the same date. There is one source of truth for the forecast. Changing any input — team capacity, issue estimates, scope growth rate, or What-If slider positions — flows through the same engine and updates all views consistently.

24. Troubleshooting

App shows "Loading..." indefinitely

• Check that your JQL filter is valid. Try running it directly in Jira's issue search.
• If Sprint Mode is on, verify you have the correct Board selected in Settings.
• Ensure the Forge app has the necessary permissions on your Jira site.

No sprints appear on the Sprints tab

• Confirm Sprint Mode is enabled in Settings.
• Verify the selected Board is a Scrum board (not Kanban).
• Check that the board has at least one sprint created.

Drag and drop is not working

• Ensure the issue is not locked (lock icon should be unlocked).
• If reordering within a sprint, make sure no column sort is active (click the sorted column header to clear it).
• Check that Read-only Mode is not enabled in Settings.
• Browser extensions that intercept drag events may interfere.

Changes are not saving

• After editing settings, click Save Configuration. The button shows "Saving..." and then "Saved!" on success.
• Check your browser console for errors if the save fails silently.

Dependency warnings are missing

• Dependencies require "blocks" / "is blocked by" link types in Jira. Other link types (relates to, duplicates) are not tracked.
• Check that the linked issues are included in your JQL filter or board.

Velocity section is empty

• Velocity requires completed sprints. Use Import from Completed Sprints to backfill historical data.
• Velocity data loads only when you are on the Sprints tab. Switch to that tab and wait for it to load.

Wrong demand values in Points Mode

• Demand sums the story points of all non-done issues. If issues are missing story points, they contribute 0 to demand.
• Check the Missing Estimates category on the Alerts tab to find issues without points.

Capacity shows 0 in Time Mode

• Time Mode calculates capacity from team members' weekly values on the Team & Capacity tab. Add at least one team member and set their Hrs/Wk.
• Check that the sprint has valid start and end dates (capacity is summed from the weekly values that overlap the sprint).
• If you see zero capacity, make sure weekly values are set for the weeks that overlap your sprint dates.

AI analysis not working

• An AI API key is required. Go to Settings → AI Features and enter a valid key for your chosen provider.
• Anthropic keys start with sk-ant-, OpenAI keys start with sk-.

What-If (Project view) shows "Issues Need Due Dates"

• What-If (Project view) requires issues with due dates to build weekly time buckets. Add due dates to your issues in Jira.

Forecast shows "Never"

• This means scope growth exceeds team throughput — new work arrives faster than it is completed.
• Either reduce scope growth (cut incoming work) or increase team capacity.
• Try disabling scope growth temporarily to see the forecast without it.

25. Technical Reference

Visual Indicators

Indicator	Meaning
Default button highlighted	Sprint uses capacity limit from Settings
Team button highlighted	Per User mode: capacity calculated from team config. Per Sprint mode: same as Default.
Manual button highlighted	Sprint capacity is a user-entered number
Team button greyed out	No team members configured on the Team & Capacity tab
Red avatar ring	User is over their capacity limit
Green avatar ring	User is within capacity
Gray avatar	User is filtered out — click to restore
Purple move badge	Issue was moved by Auto-Level
Orange move badge	Issue was manually moved during an Auto-Level session
⚠ icon on issue key	Dependency conflict (blocker finishes after this issue starts)
Lock icon (filled)	Issue or sprint is locked (excluded from Auto-Level and drag)
Blue sort arrow (↑/↓)	Column is sorted ascending or descending
Blue reorder line	Drop target indicator when reordering issues
Red due date	Issue is past due (due date before today)
T marker (purple)	Target sprint/week on cascade bar chart
P marker (green/red)	Projected delivery sprint/week on cascade bar chart

Keyboard and Mouse Shortcuts

Action	Shortcut
Select multiple issues	Click checkboxes individually
Select a range of time off days	Shift + click
Toggle individual time off days	Ctrl + click
Close column search dropdown	Esc
Add column from search	Enter

Data Storage

Project Commander stores all its data securely within your Jira Cloud instance using Atlassian Forge storage:

• Configuration — all settings, column preferences, sprint limits, per-sprint capacity overrides, locked issues, locked sprints
• Team configuration — team members, weekly capacity values, holidays, time off
• Issue orders — custom issue ordering per sprint
• Velocity data — historical sprint completion data

Issue data from your JQL filter is fetched from Jira on each page load and shared across all tabs. No issue data is stored permanently by the app.

Time Unit Conversion

Jira stores time values in seconds. Project Commander converts using an 8-hour workday:

• 1 hour = 3,600 seconds
• 1 day = 28,800 seconds (8 hours)

Capacity States

Each sprint's Default/Team/Manual toggle determines its capacity source:

Toggle State	Source
Default selected	The Capacity Limit from Settings
Team selected	Per User mode: calculated from team configuration (Points Mode: points per sprint; Time Mode: available hours minus holidays and time off). Per Sprint mode: same as Default.
Manual selected	The number the user entered

During Auto-Level, a "Use velocity as capacity" checkbox can override these with efficiency-adjusted limits based on each member's historical completion rate against their real available capacity.

Risk and Team & Capacity tabs always use team-based calculations when available, regardless of individual sprint toggles. They fall back to the Capacity Limit from Settings when no team is configured.

Auto-Level Constraints

• Maximum 10 new sprints per Auto-Level run
• New sprint dates use the Sprint Length setting (1, 2, 3, or 4 weeks) with contiguous scheduling
• New sprint capacity defaults to the average of existing sprint capacities
• Oversized issues (larger than sprint capacity) are placed in a dedicated overflow sprint

Monte Carlo Simulation Details

• 2,000 iterations (Sprint view) or 5,000 iterations (Project view) per simulation run; Compare All uses 10,000
• Each iteration draws a global trend for each variable, then blends 50% global + 50% per-user noise for each team member
• Blended per-user randomization: team-wide factors are correlated, individual variation is semi-independent
• Each iteration runs a deterministic cascade: overflow from sprint N becomes extra demand in sprint N+1
• Completion sprint is the first sprint where cumulative capacity ≥ cumulative demand (overflow ≤ 0.5 units)
• If overflow remains after the last sprint, extra sprints are estimated: ceil(overflow ÷ avg capacity), capped at 5
• Results are binned at half-sprint (or half-week) precision for smooth probability curves
• Output percentiles: 10th, 25th, 50th (median), 75th, 90th
• Confidence bands: 50% (25th–75th) and 80% (10th–90th)

Dashboard Card Formulas

Card	Formula
Schedule Adherence	Compares planned-by-now vs completed-by-now. Planned = sum(estimates) for issues due ≤ today. Completed = sum(estimates) for Done issues due ≤ today. Ahead if completed > 105% of planned, Behind if < 95%, On Pace otherwise.
Finish on Time?	Remaining = sum(remaining estimate) for non-Done issues. Weekly capacity = sum(hours/week × utilization%) per team member. Total capacity = weekly capacity × weeks until target. Ratio = capacity ÷ remaining. Yes if ratio ≥ 1.0, At Risk if ≥ 0.9, No if < 0.9.
Forecast	Velocity-based: weeks needed = adjusted remaining work ÷ weekly throughput. Projected date = today + (weeks × 7). Remaining work is multiplied by estimate accuracy ratio when estimates are consistently low. Sprint plan-based: end date of last open sprint.
Progress	sum(estimates for Done issues) ÷ sum(all estimates) × 100. Falls back to count(Done) ÷ count(All) if no estimates exist.

Deliverability

Status	Condition
Sufficient	Remaining capacity ≥ remaining work (or all work already done)
Tight	Remaining capacity ≥ 90% of remaining work
At Risk	Remaining capacity < 90% of remaining work

Per-sprint badges: DELIVERABLE if capacity ≥ demand, TIGHT if capacity ≥ 90% of demand, OVERCOMMITTED otherwise.

Scope Creep Calculation

For active sprints: original commitment = sum(points) of issues at sprint start (from Jira changelog). Current scope = sum(points) of current issues. % change = (current − original) ÷ original × 100. The expandable panel lists each issue added or removed mid-sprint, with dates from the changelog.

All Status Thresholds

Factor	Green (OK)	Amber (Caution)	Red (At Risk)
Scope Growth	≤ 10%	11% – 25%	> 25%
Team Capacity	60% – 90%	< 60% or 91% – 110%	> 110%
Team Balance	All 50% – 100%	Any >100% or <50%	Any >115% with another <60%
Delivery Rate	≥ 85%	65% – 84%	< 65%
Estimate Accuracy	80% – 110%	< 80% or 111% – 130%	> 130%
Dependency Conflicts	0	1 – 2	≥ 3

Key Constants

Constant	Value	Used In
Workday	8 hours	All time conversions (hours ↔ days)
Time (seconds → hours)	÷ 3,600	Jira remaining estimate conversion
Time (seconds → days)	÷ 28,800	Jira remaining estimate conversion (8h day)
Max new sprints (Auto-Level)	10	Auto-Level sprint creation limit
Monte Carlo iterations	2,000 (Sprint) / 5,000 (Project) / 10,000 (Compare All)	What-If simulation
Sprint length options	1, 2, 3, or 4 weeks	New sprint creation, Auto-Level