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 "Sprint Assist" or "Project Commander"
4. Click Add gadget
5. The gadget will appear on your dashboard

2. Getting Started

Project Commander uses a JQL filter to define which issues to analyze. You can optionally enable Sprint Mode if your team uses Jira sprints.

Step 1: Set Your JQL Filter

The JQL filter determines which issues appear in all analysis tabs (Feasibility, Scope, Alerts, Trends, Capacity).

1. Open Settings
2. Enter a JQL Filter to define your issue set
3. Examples:
   • project = PROJ - all issues in a project
   • project = PROJ AND status != Done - open issues only
   • labels = "release-2.0" - issues with a specific label
   • fixVersion = "2.0" - issues in a release

Step 2: Enable Sprint Mode (Optional)

If your team uses Jira sprints:

1. Find your Board ID from your Jira board URL: /boards/123
2. Enter the Board ID in Settings
3. Enable Sprint Mode to show the Sprints tab
4. Set your capacity limit and estimation mode

With Sprint Mode on, you get sprint planning, auto-level, and velocity tracking in addition to the analysis tabs.

Step 3: Save Configuration

Click Save Configuration to apply your settings.

3. Configuration

Access settings by clicking the gadget's edit button (pencil icon) on your dashboard.

Board Selection

You can configure your board in two ways:

• Enter Board ID manually - Type the board ID directly if you know it
• Select from dropdown - Click "Or select from available boards" to browse all boards you have access to. Select a board by name and the ID is filled in automatically.

Settings Reference

Setting	Description
Board ID	The ID of your Jira board. Required only when using Sprint Mode.
Sprint Mode	Toggle that controls which tabs are visible. When ON with a valid Board ID, the Sprints tab is available. Other tabs (Scope, Feasibility, Alerts, Team) are always available regardless of Sprint Mode setting.
JQL Filter	JQL query to filter issues for analysis tabs.
Include Backlog	Include backlog issues in sprint view (Sprint Mode only).
Anthropic API Key	API key for AI Insights features.
Estimation Mode	Points Mode: You manually set sprint capacity limits. Uses Story Points as the capacity metric. Time Mode: Capacity is auto-calculated from team availability (requires Team tab setup). Uses Remaining Estimate (hours/days) as the capacity metric.
Capacity Metric	Determines how work is measured. Story Points (used automatically in Points Mode) or Remaining Estimate in hours/days (used automatically in Time Mode). The metric is set automatically when you switch between Points Mode and Time Mode.
Time Unit	When using Remaining Estimate, display as Hours or Days (Days uses 8-hour workdays)
Capacity Mode	Track capacity Per Sprint (total) or Per User (individual)
Capacity Limit	Default capacity limit for sprints or users
Progress Indicator	Show work remaining as a percentage in sprint headers (None, Remaining/Original, or Work Ratio)
Sprint Length	Duration for auto-created sprints (2, 3, or 4 weeks)
Display Columns	Select which columns appear in issue tables (Key, Summary, Assignee, Points, Status, Type, Priority, Start, Due)

Time Mode Setup

When you select Time Mode in Estimation Mode, sprint capacity is automatically calculated from your team's availability. This requires setting up your team first:

1. Select Time in Estimation Mode
2. You'll see a warning banner if no team members are configured
3. Go to the Capacity tab (a warning badge ! appears when setup is needed)
4. Add team members, set their hours/week and utilization
5. Configure holidays and time off

Once configured, each sprint's capacity will automatically reflect your team's actual available hours for that period, accounting for weekends, holidays, and time off.

Issue Start and Due Date Columns

You can enable optional columns to display issue start dates and due dates. These columns provide visibility into time-based constraints that exist alongside sprint-based planning.

Why Show Issue Dates?

While sprints provide a planning container, individual issues often have their own time constraints:

• External deadlines - Customer commitments, regulatory requirements, or launch dates
• Coordination needs - Work that must align with other teams or systems
• Milestone tracking - Issues tied to roadmap milestones

The date columns make these constraints visible without leaving the sprint planning view.

Enabling Date Columns

1. Open gadget settings (Configure)
2. In the Display Columns section, enable Start and/or Due
3. Save the configuration

Date Column Features

• Format - Dates display as "Mon DD" (e.g., "Jan 14"). This compact format fits within the table while remaining readable.
• Past-due highlighting - Due dates in the past are shown in red bold text. This immediately draws attention to overdue items.
• Empty dates - Issues without dates show a dash (-) to indicate the field is empty rather than hidden.
• Disabled by default - These columns are off by default to keep the view uncluttered for teams that don't use issue-level dates.

Using Dates Effectively

Best practices for working with issue dates in Project Commander:

• Use Due Date for hard deadlines only - Not every issue needs a due date. Reserve it for genuine external constraints.
• Use Date Sync strategically - If you want all issues to reflect sprint timing, use Sync Dates. If some issues have independent deadlines, sync individual sprints or skip sync.
• Act on red dates - Past-due highlighting is a warning. Either complete the issue, adjust the date, or move it to a sprint that ends before the deadline.

4. Sprint View

The main view shows all active and future sprints from your board, plus the backlog.

Sprint Card Elements

• Sprint State Badge - Shows ACTIVE or FUTURE status
• Collapse/Expand Arrow - Click to show/hide sprint details
• Reorder Buttons - Move sprints up or down in the display
• Capacity Display - Shows used/total (e.g., "6 / 242 hrs"). Hover for a tooltip with full details. Click to set a custom limit.
• Auto/Manual Toggle - Switch between auto-calculated capacity (from team availability or velocity) and a manually set limit
• Date Range - Click to edit sprint start and end dates
• Sprint Goal - Click to add or edit the sprint goal inline
• Progress Indicator - Shows percentage of work remaining (when configured)
• User Chips - Shows points per assignee; click to filter, double-click to edit capacity
• Issues Table - List of issues in the sprint (scrollable when more than 10 issues)

Sprint Goals

Each sprint can have a goal that describes the sprint's objective. Goals are editable inline:

• View goal - The goal displays below the sprint dates as "Goal: [text]"
• Add goal - Sprints without goals show "Click to add goal"
• Edit goal - Click on the goal text to open an inline editor
• Save changes - Click Save to persist the new goal
• Cancel editing - Click Cancel to discard changes
• Clear goal - Save with empty text to remove the goal

Sprint Actions

• Start Sprint - Available for future sprints with dates set
• Complete - Available for active sprints
• Sync Dates - Sync issue dates to sprint dates
• Delete - Available for future sprints (with or without issues)

5. Sprint Management

Creating a Sprint

1. Click + Create Sprint
2. Enter the sprint name (required)
3. Optionally set start and end dates
4. Optionally add a sprint goal
5. Click Create Sprint

Editing Sprint Goals

1. Click on the goal text (or "Click to add goal" for sprints without a goal)
2. Edit the text in the input field
3. Click Save to apply changes, or Cancel to discard

Editing Sprint Dates

1. Click on the date range text (e.g., "Jan 13 - Jan 27")
2. Use the date pickers to adjust dates
3. Click Save

Starting a Sprint

• Only future sprints with dates can be started
• Click Start Sprint
• Confirm the action
• The sprint becomes active
• Note: If you already have an active sprint, a warning will appear. While Jira allows multiple active sprints, this is often unintentional. You can still proceed if your team intentionally runs parallel sprints.

Completing a Sprint

• Only active sprints can be completed
• Click Complete
• Confirm the action
• The sprint is closed and removed from view

Deleting a Sprint

• Only future sprints can be deleted (not active or completed sprints)
• Click Delete on the sprint card
• If the sprint has issues, a dialog will ask where to move them:
  • Move to Backlog - Issues are returned to the backlog
  • Move to another sprint - Select a destination sprint from the dropdown
• Click Delete Sprint to confirm
• Issues are moved first, then the sprint is deleted

If the sprint is empty, it can be deleted directly with a simple confirmation.

6. Auto-Level

Auto-Level is one of Project Commander's most powerful features. It uses an intelligent algorithm to redistribute issues while respecting dependencies, due dates, and capacity limits. It works in both sprint mode and per-user mode, saving hours of manual rebalancing work.

Why Auto-Level Exists

Manual sprint rebalancing is one of the most tedious aspects of sprint planning:

• Time-consuming - Moving dozens of issues one by one takes significant time
• Error-prone - It's easy to accidentally break dependency ordering or miss due dates
• Repetitive - Every sprint review requires similar rebalancing work
• Context-heavy - You must keep dependencies, dates, priorities, and capacities in mind simultaneously

Auto-Level automates this process while making smarter decisions than a human could make quickly.

How It Works

1. Click the Auto-Level button (only enabled when sprints/users are over capacity)
2. Choose your strategy for selecting which issues to move
3. Click Auto-Level to proceed
4. The algorithm analyzes dependencies, dates, and capacity
5. Issues are redistributed to stay under capacity limits
6. In sprint mode, new sprints are created if needed (up to 10)
7. A summary shows how many issues were moved, with any date warnings
8. After closing the dialog, Undo and Accept buttons appear

Undo and Accept

After Auto-Level completes, you have a chance to review the changes before finalizing:

• Undo - Reverses all the moves, returning issues to their original sprints. Use this if you're not satisfied with the results.
• Accept - Finalizes the changes and hides the undo option. Use this when you're happy with the redistribution.

While Undo/Accept buttons are visible, the Auto-Level button is disabled to prevent running multiple operations simultaneously. The undo option remains available until you click Accept or refresh the page.

Strategy Selector - Choosing the Right Approach

The strategy determines which issues are candidates for moving. Choose based on what matters most to your team:

Strategy	How It Works	Best For
Priority (default)	Moves lowest priority issues first. High priority work stays in earlier sprints.	Teams where business priority drives scheduling. Ensures critical work happens first.
Size	Moves largest issues first. Frees up the most capacity with fewer moves.	Teams trying to minimize changes. Large issues often have more flexibility than small ones.
Due Date	Moves issues without urgent deadlines first. Keeps time-sensitive work in place.	Teams with hard deadlines. Ensures deadline-driven work stays scheduled appropriately.

Date-Aware Placement

Auto-Level intelligently considers due dates when deciding where to place issues:

• Prefers sprints that fit - When choosing a target sprint, sprints ending before the issue's due date are ranked higher
• Shows warnings - If an issue must be moved to a sprint that ends after its due date, a warning is displayed so you know action may be needed
• Never blocks moves - Date constraints are soft warnings, not hard blocks. The algorithm will still move issues when needed to meet capacity constraints

The logic behind soft date constraints: Due dates are important but not absolute. A slight miss on a date is often better than leaving the issue in an overcrowded sprint where it might not get attention at all. Auto-Level surfaces the conflict for you to decide.

The Algorithm Explained

Understanding how Auto-Level works helps you predict its behavior:

Step 1: Dependency Analysis

The algorithm first builds a dependency graph of all issues using topological sorting (specifically Kahn's algorithm). This determines the order in which issues can potentially be scheduled:

• If Issue A is blocked by Issue B, then B must appear in the same sprint or earlier than A
• The algorithm detects circular dependencies (A blocks B, B blocks C, C blocks A) and will refuse to proceed, since such cycles have no valid ordering

Step 2: Identify Over-Capacity

The algorithm identifies which sprints (or users, in per-user mode) exceed their capacity limits and by how much.

Step 3: Select Issues to Move

Based on your chosen strategy, the algorithm selects issues from over-capacity sprints:

• Issues are sorted by the strategy criteria (priority, size, or due date)
• The algorithm selects enough issues to bring the sprint under capacity
• Issues with dependencies are moved together when needed to maintain valid ordering

Step 4: Find Target Sprints

For each issue being moved, the algorithm finds the best target sprint:

• Must have enough capacity for the issue
• Must respect dependency ordering (no earlier than blockers)
• Prefers sprints that fit the issue's due date
• Creates new sprints if no existing sprint works

Step 5: Execute Moves

All moves are executed as a batch, with a summary showing what changed and any warnings about date conflicts.

Smart Algorithm Guarantees

The Auto-Level algorithm provides these guarantees:

• Dependencies always respected - Issues are never placed before their blockers. This is a hard constraint that cannot be violated.
• Cycles detected and reported - Circular dependencies are identified before any moves occur, preventing invalid states.
• Original positions preserved when possible - Issues only move when necessary. The algorithm doesn't shuffle things around arbitrarily.
• Oversized issues distributed - Issues larger than sprint capacity are spread across sprints (one per sprint) rather than accumulating in one place.

Per-User Mode Behavior

When capacity mode is set to "Per User", Auto-Level balances each user's workload individually:

• User-specific analysis - Identifies users over their capacity limit in each sprint
• User-specific moves - Moves that user's excess issues to sprints where they have room
• Empty sprint handling - For sprints with no issues yet, uses the sprint capacity limit as the user default
• Dependency respect - Dependencies are still honored, even when balancing per-user

This mode is particularly valuable when team members have different skill sets and certain issues must be assigned to specific people.

Auto-Level Limitations

Understanding what Auto-Level cannot do helps set appropriate expectations:

• Cannot break cycles - If circular dependencies exist, Auto-Level cannot resolve them. You must fix the dependencies in Jira first.
• Cannot fit oversized issues - An issue larger than your capacity limit cannot fit in any sprint. It will still be moved but the sprint will remain over capacity.
• Creates sprints up to a limit - The algorithm creates at most 10 new sprints to prevent runaway growth.
• Date conflicts may occur - When capacity and date constraints conflict, capacity wins. Check the warnings.

7. Drag and Drop

Move issues between sprints by dragging and dropping. You can move single issues or select multiple issues for batch moves.

Moving a Single Issue

1. Click and hold on any issue row
2. Drag towards another sprint
3. The page auto-scrolls when you drag near the top or bottom edge (within 100 pixels)
4. Drop the issue on the target sprint (highlighted with a blue border)
5. The issue moves immediately (optimistic UI update)

Multi-Select Drag and Drop

Move multiple issues at once using the checkbox selection:

1. Use the checkboxes in the first column to select issues
2. Select issues from one or more sprints
3. A selection indicator shows how many issues are selected
4. Drag any selected issue to move all selected issues together
5. Drop on the target sprint - all selected issues move as a batch
6. Selection is cleared after a successful drop

Selection Tips

• Use the checkbox in the sprint header to select/deselect all issues in that sprint
• Click Clear Selection in the header to deselect all issues
• The selection indicator shows the count and total points of selected issues

Auto-Scroll Feature

When dragging issues, the page automatically scrolls to help you reach distant sprints:

• Scroll down - Drag to the bottom edge of the viewport
• Scroll up - Drag to the top edge of the viewport
• Scroll speed increases as you get closer to the edge
• Release the mouse to stop scrolling

Moving to Backlog

• Drag an issue (or selected issues) to the Backlog section at the bottom
• If the backlog is empty, a drop zone appears when dragging
• Issues are removed from sprints and returned to the backlog

8. Date Synchronization

Keep issue dates aligned with sprint dates for accurate roadmaps and reports. Date synchronization bridges the gap between sprint-based planning and date-based reporting.

Why Date Sync Matters

Jira has two parallel scheduling systems that often conflict:

• Sprint-based - Issues are assigned to sprints, which have start and end dates
• Date-based - Issues have individual Start Date and Due Date fields

These systems don't automatically sync. An issue in "Sprint 5" (ending Jan 31) might have a Due Date of "Dec 15" from an earlier plan. This creates problems:

• Timeline views show wrong dates - Roadmaps and Gantt charts use issue dates, not sprint dates
• Reports are misleading - Date-based reports don't reflect actual sprint planning
• Due date alerts fire incorrectly - Issues appear overdue when they're simply scheduled for a future sprint

Date Sync solves this by aligning issue dates with their sprint schedule.

Sync Dates for a Sprint

1. Ensure the sprint has start and end dates set
2. Click Sync Dates on the sprint card
3. All issues in the sprint will have their:
   • Start Date set to the sprint's start date
   • Due Date set to the sprint's end date

This is useful when you've just moved issues into a sprint and want their dates to reflect the new schedule.

Sync All Dates

• Click Sync All Dates in the header
• This syncs dates for all sprints that have dates configured
• Use this after major rebalancing or when setting up a new release plan

Remove All Dates

• Click Remove All Dates to clear start/due dates from all issues
• A confirmation dialog prevents accidental removal
• Use this when dates have become stale and you want to start fresh

9. Dependency Warnings

Project Commander warns you when issue dependencies create scheduling conflicts. This is one of the most valuable features for teams with complex, interdependent work.

Why Dependency Warnings Matter

In complex projects, issues often depend on each other. A feature might require an API to be built first. A bug fix might depend on a design decision. Jira captures these relationships through issue links, but it does nothing to enforce them during sprint planning.

The result: teams frequently schedule blocked issues before their blockers, only discovering the problem mid-sprint when someone tries to start work and realizes they're waiting on something that hasn't been done yet. This leads to:

• Blocked developers - People can't start their assigned work
• Sprint disruption - Mid-sprint reshuffling to find alternative work
• Missed commitments - Work that was "planned" never actually had a chance to complete

Project Commander surfaces these conflicts during planning, when you can still fix them.

What It Detects

A dependency violation occurs when:

• Issue A is blocked by Issue B (using Jira's "blocks" link type)
• But Issue B is scheduled in a later sprint than Issue A

This means you're planning to work on a blocked issue before its blocker is complete - a logical impossibility that will cause problems during execution.

Visual Indicators

Dependency violations are clearly highlighted in the UI:

• Warning icon - Issues with violations show an orange warning icon (⚠) next to the issue key
• Tooltip details - Hover over the warning to see which blocker is in a later sprint and where it's scheduled
• Header count - The sprint header shows a count of blocked issues, so you can see problems at a glance
• Row highlighting - Affected rows have an orange background to draw attention

Resolving Violations

There are two ways to fix a dependency violation:

1. Move the blocker earlier - Drag the blocking issue to the same sprint or an earlier sprint than the blocked issue. This is usually the right approach if the blocker is genuinely prerequisite work.
2. Move the blocked issue later - Drag the blocked issue to the same sprint or a later sprint than its blocker. This is appropriate if the blocked issue can wait.

Auto-Level automatically respects dependencies, so running Auto-Level will fix dependency violations as part of the rebalancing process.

Common Scenarios

Scenario	What It Means	Recommended Action
High-priority blocked by low-priority	Critical work is waiting on less important work	Raise priority of the blocker or question the dependency
Many issues blocked by one	Single point of failure in your plan	Ensure the blocker is prioritized and properly estimated
Cross-team dependencies	Your sprint depends on another team's work	Coordinate timing or add buffer to your schedule

10. Filtering

Work by User Summary

The "Work by User (in sprints)" section displays a row of chips showing workload distribution across your team:

• What it shows - Total story points assigned to each team member
• Scope - Aggregates points from all active and future sprints (excludes backlog)
• Hover - Shows issue count and total points (e.g., "12 issues, 45 pts")
• Click - Filters the view to show only that user's issues

This gives you a quick overview of how work is distributed across the team without having to expand each sprint.

Global Filter by User

1. Use the Filter by dropdown in the header
2. Select a team member's name
3. Only issues assigned to that person are shown across all sprints
4. Point totals are recalculated for the filtered view

Per-Sprint User Filtering

Filter issues within individual sprints by clicking on user chips:

• Click a user chip - Filter that sprint to show only that user's issues
• Multi-select - Click additional users to show multiple users' issues
• Visual indication - Selected users are highlighted in blue
• Filter status - Shows "Showing X of Y issues" when filter is active
• Clear filters - Click the "Clear filters" button to remove all user filters

User Capacity Mode

When in Per User capacity mode, the user chips serve dual purposes:

• Single-click - Toggle filter for that user
• Double-click - Edit the user's capacity limit

Quick Filter from Header Chips

• Click on any name in the "Work by User" summary
• The view filters to that user globally
• Click again to clear the filter

Clearing Filters

• Global filter - Select "All Users" from the dropdown, or click the X button
• Per-sprint filter - Click "Clear filters" button in the sprint, or click each selected user again

11. Velocity Tracking

Velocity tracking is a cornerstone feature that transforms sprint planning from guesswork into data-driven decision making. By recording what your team actually delivers, Project Commander helps you predict future capacity with confidence.

Why Velocity Tracking Matters

Without velocity data, teams face common challenges:

• Optimistic planning - Teams consistently overestimate what they can deliver, leading to missed commitments
• No learning loop - Without historical data, teams can't improve their estimation accuracy over time
• Invisible performance trends - Gradual changes in team productivity go unnoticed until they become problems
• Unfair workload distribution - Without per-user data, imbalances in individual workloads remain hidden

Project Commander's velocity tracking solves these problems by capturing actual delivery data and making it actionable for future planning.

Understanding the Velocity Panel

The Velocity Panel appears in the sprint view header and provides insights into your team's delivery capacity:

• Expected Velocity - Predicted points for the current sprint based on historical performance. This is your most reliable indicator of what the team can actually deliver.
• Trend Indicator - Arrow showing if velocity is improving (up), declining (down), or stable. Helps identify patterns before they become problems.
• Click to expand - View detailed statistics and sprint history

Velocity Statistics Explained

When expanded, the panel shows four key metrics. Understanding what each means helps you use them effectively:

Metric	Description	How to Use It
Avg Velocity	Average points completed per sprint	Use this as your baseline capacity limit. If average velocity is 32 points, plan for 30-35 points per sprint.
Pts/Week	Average points completed per week (normalized for sprint length)	Useful when sprint lengths vary. Allows apples-to-apples comparison across different sprint durations.
Efficiency	Percentage of planned capacity actually completed (Completed / Planned x 100)	Target 85-100%. Below 80% suggests over-planning. Above 100% means you're under-utilizing capacity.
Completion	Average completion rate across sprints	Consistency indicator. High variability suggests unpredictable scope or estimation issues.

The Logic Behind Velocity Calculations

Project Commander uses a rolling average approach to velocity calculation:

1. Recent sprints weighted equally - The last N sprints (configurable, default 5) are averaged. This balances stability with responsiveness to change.
2. Normalization by time - Points per week normalizes for varying sprint lengths. A 20-point 1-week sprint equals a 40-point 2-week sprint in productivity terms.
3. Trend detection - The trend compares recent sprints to older ones. A consistent increase or decrease over 3+ sprints triggers the trend indicator.

Team vs Per-User View

The velocity panel has two tabs, each serving different purposes:

Team Tab

Provides a holistic view of team delivery. Use this for:

• Setting sprint capacity limits
• Communicating delivery expectations to stakeholders
• Identifying overall productivity trends

Shows sprint history with:

• Sprint name and dates
• Sprint length (in weeks)
• Capacity and completed points
• Points per week (normalized)
• Efficiency percentage
• Best sprint marked with star - your team's peak performance
• Lowest velocity sprint marked with down arrow - may indicate issues worth investigating

By User Tab

Reveals individual contribution patterns. Use this for:

• Identifying team members who may need support
• Recognizing high performers
• Balancing workload assignments
• Having data-driven performance conversations

Shows individual team member performance:

• User name - Team member
• Sprints - Number of sprints participated in (context for reliability of data)
• Avg Planned - Average points assigned per sprint (is this person receiving appropriate workload?)
• Avg Completed - Average points completed per sprint (actual delivery)
• Efficiency - Individual completion rate (green if >=90%, red if <70%)
• Trend - Individual performance trend (up = improving, down = declining, right = stable)

How Velocity is Captured

Velocity is automatically captured when you complete a sprint. This ensures data reflects actual delivery, not plans:

1. Click Complete on an active sprint
2. If there are incomplete issues, choose a rollover option:
   • Move to Backlog - Incomplete issues go to backlog
   • Move to existing sprint - Select a future sprint
   • Create new sprint - Create a new sprint for rollover
3. The system records:
   • Total points planned at sprint start
   • Total points completed (done issues)
   • Sprint duration for normalization
   • Per-user breakdown (if in per-user mode)

Configuring Velocity

In the Configuration panel:

• Velocity Sprint Count - Number of past sprints to include in calculations (default: 5).
  • Lower values (3-4): More responsive to recent changes, but more volatile
  • Higher values (6-8): More stable predictions, but slower to adapt to team changes

Velocity Panel Actions

• Refresh - Reload velocity data from storage (useful if data was updated externally)
• Clear - Delete all velocity history (requires confirmation). Use this when:
  • Team composition has changed significantly
  • Your estimation approach has changed
  • Historical data no longer represents current capability

Using Velocity Data Effectively

Best practices for leveraging velocity:

1. Set capacity based on velocity, not wishes - If your average velocity is 35 points, planning 50 points sets the team up for failure
2. Plan for 80-90% of average velocity - Leave buffer for uncertainty and unplanned work
3. Investigate outliers - Very high or low sprints usually have explanations (holidays, incidents, heroic effort). Understand them to improve future planning.
4. Watch for trends - Declining velocity over 3+ sprints signals a problem. Increasing velocity might indicate process improvements or unsustainable pace.
5. Use per-user data for balancing - If one person consistently has low efficiency while another has 100%+, workload distribution may need adjustment.

12. Feasibility Analysis

The Feasibility tab answers the critical question every project manager asks: "Can we deliver by the deadline?" It analyzes total demand against available capacity across your timeline, showing whether your plan is achievable.

Understanding the Feasibility Score

The Feasibility Score is a percentage that indicates plan health:

Score	Status	Meaning
80-100%	On Track	Capacity exceeds demand. Plan is achievable with buffer.
60-79%	At Risk	Capacity is tight. Plan may slip without intervention.
0-59%	Critical	Demand exceeds capacity. Plan will fail without changes.

Period Bar

The period bar at the top of the Feasibility tab lets you analyze different time ranges:

• All Time (default) - Shows the full project from earliest start date to latest due date across all issues. Navigation arrows are disabled since this shows everything.
• Weekly - Analyze capacity week by week. Use the arrows to move forward/backward.
• Biweekly - Two-week periods, useful for sprint-aligned analysis.
• Monthly - Calendar month view for monthly planning cycles.
• Quarterly - Q1-Q4 view for roadmap planning.
• Yearly - Annual view for long-term planning.

When you select a period other than "All Time", issues are filtered to show only those that overlap with the selected time range. This helps you focus on specific planning horizons.

The Feasibility Chart

The chart visualizes how capacity and demand evolve over time:

• Cumulative Capacity (green dashed) - Total available hours/points as they accumulate over time.
• Cumulative Demand (blue dashed) - Total work required as it accumulates over time.
• Scope (purple dashed) - Cumulative original estimates, showing the planned scope. In Points Mode this shows story points; in Time Mode it shows original estimate hours.
• Time Spent (orange solid) - Actual work completed. Compare against Scope to track progress.

Click legend items to show/hide individual lines. This is useful for focusing on specific metrics.

Reading the Chart

A healthy project shows:

• Capacity line above the Demand line (buffer exists)
• Time Spent tracking close to Scope (on-track progress)
• Lines converging at the deadline (work completes on time)

Warning signs:

• Demand line crossing above Capacity (overcommitment)
• Large gap between Scope and Time Spent (behind schedule)
• Scope line growing faster than expected (scope creep)

Stat Cards

Nine stat cards provide key metrics at a glance, arranged in two rows:

Stat	Description
Total Demand	Remaining work to be done (hours or points)
Total Capacity	Available capacity in the time period
Time Spent	Work already logged
Buffer	Capacity minus Demand. Positive = surplus, Negative = deficit (shown in red)
Feasibility	Overall feasibility score as a percentage. Click to expand and see the score breakdown factors.
Confidence	Data quality score (high/medium/low). Click to expand and see which data factors affect reliability.
% Complete	How much work is finished: 1 - (remaining / original). Shows overall progress toward completion.
Work Ratio	Percentage of work still remaining: remaining / (spent + remaining). Lower is better.
Efficiency	Time spent vs original estimate: spent / original. Values near 100% indicate accurate estimation.

Target Date Forecast

Set a target date to see when the project is forecasted to actually complete:

• Check Target Date and select a date using the date picker
• A forecast banner shows the projected completion date based on current capacity and demand
• If the forecast is later than the target, it shows how many days late (e.g., "Completes: Mar 27 (32 days late)")
• A red dashed vertical "Target" line appears on the chart for visual reference

Team Member Filter

Filter the analysis by individual team members using the filter chips below the period bar. Click "All" to see the full team, or click individual names to see their specific demand, capacity, and metrics.

Resource Breakdown

When team members are configured, the Feasibility tab shows a resource breakdown with each person's:

• Issue count and demand assigned
• Load percentage
• Status (overloaded, on_track, under_utilized, idle)

This helps identify which team members need work redistributed.

13. Scope Tab

The Scope tab tracks how your project scope changes over time, helping you identify and address scope creep before it derails your sprint or project.

What is Scope Creep?

Scope creep occurs when work is added to a sprint or project after the initial commitment. While some scope changes are necessary, uncontrolled scope creep leads to:

• Missed deadlines as more work is added than removed
• Team burnout from constantly expanding commitments
• Stakeholder frustration when promised work isn't delivered
• Inaccurate velocity data that undermines future planning

The Scope Chart

The main visualization shows how scope evolves over time:

• Scope Line - Total estimated work (points or hours) over time
• Burned Line - Work completed over time
• Sprint Markers - Vertical lines showing sprint boundaries (optional)

A healthy project shows the Burned line tracking close to or catching up with the Scope line. If the Scope line keeps rising faster than Burned, you have a scope creep problem.

Period Filtering

Use the period bar to focus on different time ranges:

• All Time - Complete project history
• Weekly / Biweekly / Monthly - Shorter analysis windows
• Quarterly / Yearly - Long-term trends

Navigation arrows let you move forward and backward through periods.

Scope Stat Cards

Three stat cards at the top summarize the current state:

Metric	Description
Scope	Total estimated work across all issues (points or hours)
Burned	Work completed (resolved issues)
Remaining	Work still to be done (Scope minus Burned)

Weekly Breakdown Table

Below the chart, a detailed breakdown table shows scope changes period by period:

• Period selector - Switch between Weekly, Biweekly, Monthly, or Quarterly views
• Columns - Week, Issue count, Assignee, Added (new work), Burned (completed work), Remaining
• Expandable rows - Click any period row to see the individual issues added or completed in that period
• Color coding - Added values shown in blue, Burned values in green

This table helps you identify exactly when scope was added and how much work was completed each period, making it easy to spot patterns in scope creep.

14. Alerts Tab

The Alerts tab provides a centralized view of all issues that need attention. Instead of discovering problems during sprint execution, surface them during planning.

Alert Categories

Issues are grouped into six collapsible categories. Click any section header to expand or collapse it:

Done with Remaining Work

Issues marked as Done but still showing remaining estimate (e.g., "Marked as done but has 4h remaining"). This usually indicates incomplete work or forgotten time tracking cleanup.

Overdue

Issues with due dates in the past that aren't completed. These need immediate attention - either complete the work, update the due date, or communicate the delay.

Dependency Conflicts

Issues with scheduling conflicts due to dependencies, including circular dependencies. Shows issues blocked by work in later sprints, and dependency chains that form cycles.

Child After Parent

Child issues (subtasks) scheduled after their parent issue's due date. This indicates a planning inconsistency where subtasks would need to be completed after the parent is due.

Missing Dates

Issues without start or due dates when date tracking is important for your workflow. Useful for teams that rely on timeline views.

Missing Estimates

Issues without story points or time estimates. Unestimated work makes capacity planning unreliable and can hide significant effort.

Alert Counts

The tab badge shows the total alert count, so you can see at a glance if there are issues needing attention. Alerts are categorized by severity:

• Errors (Red) - Critical issues that will likely cause problems
• Warnings (Yellow) - Issues that may cause problems

Taking Action

Click any issue key to open it in Jira and address the problem. The alerts list refreshes when you return to Project Commander.

15. Trends Tab

The Trends tab tracks how your project data changes over time, helping you identify patterns in scheduling and estimation. It has two sub-views accessible via toggle buttons at the top.

Due Date Delays

Tracks issues whose due dates have been pushed back. This reveals scheduling patterns and helps identify chronic delays before they compound.

Stat Cards

Stat	Description
Delayed	Number of issues with delayed due dates (out of total issues)
Avg Change	Average delay per affected issue
Reschedules	Total number of date changes across all issues
Max Change	Largest single delay with the affected issue key

Issue List

Below the stat cards, issues are listed with their total delay, number of changes, and current status. Sort by:

• Total Delay - Largest cumulative delays first
• # Changes - Most frequently rescheduled first
• Most Recent - Most recently changed first

Expand any issue to see the full history of date changes.

Estimate Changes

Tracks issues whose time or point estimates have been revised. This reveals estimation accuracy patterns and helps improve future planning.

Stat Cards

Stat	Description
Re-Estimated	Number of issues with changed estimates (out of total)
Avg Change	Average estimate change per affected issue
Re-Estimates	Total number of estimate revisions across all issues
Max Change	Largest single estimate change with the affected issue key

Issue List

Sort by Total Change, # Changes, or Most Recent. Expand any issue to see its full estimation history.

Using Trends Effectively

Look for patterns that indicate:

• Chronic rescheduling - Issues with 3+ date changes may need better scoping or clearer requirements
• Estimate growth - Estimates that consistently increase suggest underestimation during refinement
• Concentrated delays - If delays cluster around specific team members or issue types, address the root cause
• Improving accuracy - Fewer re-estimates over time indicates better planning maturity

Demo Mode

Enable Demo Mode to see sample trends data with realistic delay and estimate change patterns. This helps you understand what the visualizations will look like once you have real data.

16. Capacity Planning

Project Commander provides visual warnings when capacity limits are exceeded. Capacity planning is one of the most critical aspects of successful sprint management, yet Jira's native backlog view offers no support for it.

Why Capacity Planning Matters

Without capacity limits, teams commonly experience:

• Chronic overcommitment - Teams agree to more work than they can realistically complete, leading to missed deadlines and burnout
• Unpredictable delivery - Stakeholders can't rely on sprint commitments because completion rates vary wildly
• Hidden workload imbalances - Some team members are overloaded while others have room for more work
• Sprint spillover - Incomplete work rolls over sprint after sprint, creating a "zombie backlog"

Project Commander's capacity planning addresses these issues by making workload visible and actionable before problems occur.

Per Sprint Mode

In this mode, the total points/hours for all issues in a sprint are compared against the sprint limit. This is the simpler approach and works well for teams that:

• Have relatively even workload distribution among team members
• Don't need to track individual capacity
• Want a quick overview without per-person details

Visual indicators:

• Sprints over capacity show a red border and warning banner
• The progress bar turns red when over limit
• Click "Capacity Limit: X pts" to set a custom limit for individual sprints

Per User Mode

In this mode, each team member's workload is tracked against individual limits. This mode provides deeper insight and is recommended for teams that:

• Have varied skillsets where certain issues can only be assigned to specific people
• Need to balance workload across team members
• Want to identify bottlenecks before they cause delays
• Have team members with different availability (part-time, vacation, etc.)

Visual indicators:

• User chips show points and limit (e.g., "John: 15/20")
• Users over capacity are highlighted with a warning icon
• Click any user chip to set a custom capacity for that user in that sprint
• Custom limits show with an asterisk (*)

Setting Effective Capacity Limits

Determining the right capacity limit is crucial. Here's a practical approach:

1. Start with historical data - Look at your velocity tracking to see how many points your team actually completes per sprint
2. Account for non-sprint work - Teams typically spend 10-20% of time on meetings, support, and unplanned work
3. Build in buffer - Set capacity at 80-90% of theoretical maximum to account for uncertainty
4. Adjust based on experience - If you consistently under or over-deliver, adjust limits accordingly

Oversized Issue Warnings

When an individual issue exceeds the sprint capacity limit, it displays a warning:

• A yellow warning icon (⚠) appears next to the issue's points/hours
• The points value is displayed in red
• Hover over the warning to see a tooltip explaining the issue

Why oversized issues are problematic: An issue larger than your sprint capacity cannot, by definition, be completed within a single sprint. This creates several problems:

• The sprint will always be over capacity if this issue is included
• Progress is invisible until the entire issue is complete
• Auto-Level cannot fit the issue into any sprint without exceeding capacity

Recommended actions for oversized issues:

• Break it down - Split the issue into smaller subtasks or child issues that can each be completed within a sprint
• Increase capacity - If the issue genuinely requires this much effort, consider increasing the sprint capacity limit
• Accept the exception - Some work simply doesn't fit sprint boundaries; acknowledge that this sprint will be over capacity

Progress Indicator

The progress indicator shows the percentage of work remaining in each sprint, displayed next to the capacity in the sprint header. This helps you understand how much work is left during sprint execution.

Configuration Options

Option	Formula	Best For
None	-	Hide the progress indicator
Remaining / Original	Remaining Estimate / Original Estimate x 100	Tracking progress against original scope. Shows how much of the originally planned work remains.
Work Ratio	Remaining / (Time Spent + Remaining) x 100	Tracking actual completion including logged work. More accurate when estimates change during work.

Understanding the Logic

Remaining / Original is best when your team estimates accurately upfront. If you originally estimated 40 hours and 10 hours remain, you're 75% complete. This method rewards accurate estimation.

Work Ratio is best when estimates evolve during work. If you've logged 30 hours and estimate 10 more hours remaining, you're 75% complete regardless of the original estimate. This method adapts to reality.

17. Capacity Tab

The Capacity tab answers a fundamental planning question: "How much work can my team handle?" It combines team member availability with current workload to help managers balance assignments and plan capacity effectively.

Purpose

While the Sprints tab shows what work is planned, the Team tab shows who is doing the work and whether they have the capacity for it. Use this tab to:

• See each team member's current workload at a glance
• Identify overloaded or underutilized team members
• Plan for time off and holidays that reduce availability
• Calculate team capacity for different time periods (weekly, monthly, quarterly)

Team Members Section

The main table shows all team members with their capacity settings and current workload. Team members are automatically populated from sprint assignees.

Period Bar

Above the team table, the period bar controls what time range capacity is calculated for:

• Date Navigator (left arrow, date, right arrow) - Move forward or backward through time periods. The display format changes based on period type (e.g., "Feb 3 - Feb 9, 2026" for weekly, "Q1 2026" for quarterly).
• Period Selector - Choose between Weekly, Biweekly, Monthly, Quarterly, or Yearly views. Use weekly for sprint planning, monthly for roadmap planning, quarterly for resource planning.

Table Columns

Column	Purpose
Name	Team member name with avatar. Members auto-populate from sprint assignees.
Hours/Week	How many hours this person works per week. Part-time = 20, Full-time = 40. Click to edit.
Util %	What percentage of work hours are productive (after meetings, email, etc.). 80% is typical. For example: 40 hrs x 80% = 6.4 effective hours/day. Click to edit.
Time Off	Combined hours for holidays and PTO in the selected period. Hover to see breakdown (e.g., "Holidays: 8h, PTO: 16h").
Net Hours	Final available capacity = Effective hours x work days - holidays - time off.
Points / Estimate	In Points Mode: story points assigned. In Time Mode: estimated hours (from Jira's Original Estimate field). Only includes sprints that overlap with the selected period.
Issues	Click to expand a dropdown showing each assigned issue with key, summary, and points.
Status	Visual indicator comparing workload to capacity. See status descriptions below.

Status Indicators

Status	Threshold	Meaning
OVERLOADED	>115% of capacity	Team member has too much work assigned. Redistribute issues or extend timelines.
OPTIMAL	90-115% of capacity	Team member is well-utilized. Ideal workload balance.
AVAILABLE	60-90% of capacity	Team member has some room for additional work.
UNDERLOADED	<60% of capacity	Team member may be able to take on more work or assist others.

Net Hours Calculation

Net Hours represents the actual available working hours after accounting for all factors:

Example: For a team member with 40 hrs/week, 80% utilization, 20 work days in the period, 1 holiday, and 8 hours of PTO:

• Effective Hours/Day = (40 / 5) x 0.80 = 6.4 hours/day
• Net Hours = 6.4 x 20 - 6.4 - 8 = 128 - 6.4 - 8 = 113.6 hours

Time Off Section

The Time Off section provides a calendar view for managing individual PTO. It includes the same period bar as the Team Members section, so both stay in sync.

• Period Bar - Same date navigator and period selector as Team Members. Changing the period updates both sections.
• Member Filter - Filter chips to show time off for specific team members.
• Calendar - Click a day to select, Ctrl+click to toggle multiple, Shift+click for range selection.
• Existing time off entries display with team member initials on the calendar.

The calendar makes it easy to visualize coverage gaps and overlapping vacations.

Company Holidays Section

Company holidays affect all team members equally. Unlike time off, holidays are shared across the entire team.

• Add holidays with a date and name
• Check the Yearly checkbox to make a holiday recurring (e.g., Christmas repeats every December 25)
• Holidays automatically deduct from Net Hours for all team members

Capacity Periods Explained

Period	Duration	Best For
Weekly	7 days	Sprint-level planning (matches typical 1-week sprints)
Biweekly	14 days	Two-week sprint planning
Monthly	Calendar month	Default view, good for monthly planning cycles
Quarterly	Q1-Q4	Roadmap planning and resource allocation
Yearly	Calendar year	Annual capacity planning and budgeting

18. AI Insights

The AI Insights tab brings artificial intelligence to your sprint planning, providing analysis and recommendations that would take hours to compile manually.

Setting Up AI Insights

AI Insights requires an Anthropic API key to function:

1. Go to Settings (gear icon)
2. Scroll to AI Features section
3. Enter your Anthropic API key
4. Click Save

Without an API key, AI analysis buttons will be disabled and a warning banner will appear.

AI Analysis Sections

The AI Insights tab contains multiple analysis types, each accessible via the sub-navigation:

Overview

Shows the status of all AI agents and recent analysis actions. Use this as your starting point to see what's available.

What If? Scenario Analysis

Ask hypothetical questions and get AI-powered impact analysis. Example scenarios:

• "What if we add 15 more story points to this sprint?"
• "What if we lose one team member for a week?"
• "What if we need to extend the deadline by 3 days?"
• "What if we move the 3 largest issues to next sprint?"
• "What if our velocity drops by 20%?"

The AI analyzes your current sprint state and provides:

• Impact Assessment - Effects on capacity, schedule, risk, and team
• Recommendations - Prioritized action items
• Alternative Scenarios - Other approaches to consider

Scope Monitor

AI-powered analysis of scope creep patterns. Identifies when scope is growing faster than expected and suggests interventions.

Blockers

Predicts which issues are likely to become blocked based on patterns in your sprint data. Click "Analyze with AI" to get predictions with confidence scores and suggested actions.

Standup

Generates a daily standup summary from your sprint activity. Includes:

• Sprint day and burndown status
• AI-generated summary of progress
• Per-person breakdown of work
• Suggested discussion topics

Retro

Analyzes completed sprints to surface insights for retrospectives:

• Team health indicators with trends
• Key insights with recommendations
• Things to celebrate
• Areas for improvement

Refinement

Checks backlog stories for readiness before sprint commitment. Evaluates:

• Story clarity and completeness
• Acceptance criteria quality
• Estimate appropriateness
• Overall readiness status

Planning

AI-assisted sprint planning suggestions including:

• Velocity forecast with confidence range
• Team capacity analysis
• Suggested stories with risk assessment
• Warnings about potential issues

Demo Mode

Enable Demo Mode to see sample AI analysis without using API credits. This helps you understand what each analysis type provides before running it on your real data.

19. Troubleshooting

Gadget Shows "Loading..." Forever

• Check that a Board ID is configured
• Verify the Board ID is correct
• Refresh the dashboard page
• Try removing and re-adding the gadget

No Sprints Appear

• Ensure the board has active or future sprints
• Completed/closed sprints are not shown
• Check that the Board ID matches the correct board

Drag and Drop Not Working

• Ensure you're dragging the entire row, not just a link
• Check for browser extensions that might interfere
• Try refreshing the page

Changes Not Saving

• Check your Jira permissions for the project
• Ensure you have permission to edit issues and sprints
• Look for error messages in the gadget

Dependency Warnings Not Showing

• Dependencies must be created using Jira's "blocks" link type
• Other link types (relates to, duplicates, etc.) are not checked
• Refresh the gadget to reload link data

Velocity Panel Shows "No velocity data yet"

• You need to complete at least one sprint to start tracking velocity
• Velocity is captured when you click Complete on an active sprint
• Check the "By User" tab - it requires Per User capacity mode to show data

Per-User Velocity Not Showing

• Enable "Per User" capacity mode in Configuration
• Complete sprints after enabling per-user mode
• Historical sprints completed before enabling won't have user data

20. Technical Reference

For detailed technical documentation of all UI elements, user actions, and backend logic, see the UI Documentation.

Visual Indicators Reference

Indicator	Meaning
Red sprint card border	Sprint is over capacity
Green points display	Sprint is under capacity
⚠ on issue key	Dependency violation (blocked by issue in later sprint)
⚠ on points	Issue exceeds capacity limit (oversized)
Asterisk (*) on limit	Custom limit set (different from default)
Red user chip	User over capacity (in user capacity mode)
Blue user chip	User filter active (showing only this user's issues)
X% remaining	Progress indicator showing work completion percentage
Red due date text	Issue due date is in the past (overdue)
"Click to add goal"	Sprint has no goal set; click to add one
Up arrow in velocity badge	Velocity is trending upward (improving)
Down arrow in velocity badge	Velocity is trending downward (declining)
Star in velocity table	Best sprint by completed points
Down arrow in velocity table	Lowest velocity sprint
Green efficiency %	User efficiency >=90% (high performer)
Red efficiency %	User efficiency <70% (needs attention)

Keyboard Shortcuts

Context	Key	Action
User capacity edit	Enter	Save changes
User capacity edit	Escape	Cancel editing