Project Commander Docs ← Back to site

Sprints Tab — Feature Guide

Sprints tab as it opens, with Closed Sprints: Hidden — the toolbar and search row, the active Sprint 7 card open with its Overcommitted badge, Remaining demand, Remaining capacity, Progress and Scope change, its Sprint / Status buttons, Sync due dates, Complete sprint and goal, the issue table and the folded Team & Capacity line, and the top of the Sprint 8 card beneath
Sprints tab as it opens, with Closed Sprints: Hidden — the toolbar and search row, the active Sprint 7 card open with its Overcommitted badge, Remaining demand, Remaining capacity, Progress and Scope change, its Sprint / Status buttons, Sync due dates, Complete sprint and goal, the issue table and the folded Team & Capacity line, and the top of the Sprint 8 card beneath
Sprints tab as it opens — the toolbar and search row, the active Sprint 7 open with its mode buttons, goal, issue table and Team & Capacity fold, the future Sprints 8, 9 and 10 closed on one row each with their Deliverable or Overcommitted badge, demand, capacity, load and scope, and the Backlog card at the foot
Sprints tab as it opens — the toolbar and search row, the active Sprint 7 open with its mode buttons, goal, issue table and Team & Capacity fold, the future Sprints 8, 9 and 10 closed on one row each with their Deliverable or Overcommitted badge, demand, capacity, load and scope, and the Backlog card at the foot

What it’s for

The Sprints tab is the single execution view for a project’s sprint cadence. It combines sprint planning, retrospectives, status, and risk analysis into one stack of expandable sprint rows plus a backlog row. From here a planner can:

The tab is strictly per-project. When the project picker in the tab bar is set to Program view (offered when more than one project is registered), the tab is replaced with a notice headed Pick a specific project to view the Sprints tab, because sprint cadences from different projects cannot be summed.

With the project's Sprint Mode checkbox turned off (Projects tab, Add / Edit Project form), the tab is named Tasks instead, the toolbar is not shown, and the issues are listed in one card named Tasks.

Toolbar

Sprints toolbar — Collapse all sprints, List View, Demand by User, Velocity, Auto-Level, and the Closed Sprints dropdown
Sprints toolbar — Collapse all sprints, List View, Demand by User, Velocity, Auto-Level, and the Closed Sprints dropdown

A single row at the top of the tab. Left to right: Collapse all sprints, List View, Demand by User, Velocity, Auto-Level, and the Closed Sprints dropdown. The issue search, Create sprint and Create Issue sit on the row beneath it (see JQL Search).

Collapse all sprints / Expand all sprints

Toggles every sprint row plus the backlog open or closed at once. The label flips to Expand all sprints when everything is already closed.

Which sprints start open: only the active one. Every future and closed sprint starts closed, and the backlog starts closed too — unless the backlog is the only card on the screen (a board with no sprints, or task-list mode), in which case it starts open so the tab is not one shut header. Once a row has been opened or closed by hand, that choice is remembered and the default no longer applies.

List View / Sprint View

List View replaces the per-sprint cards with a single searchable, sortable table of every issue across the sprints on screen plus the backlog. The first column is Sprint (the backlog's issues read Backlog), and the table opens sorted by it. The search box reads Search N issues… and filters across key, summary, assignee, sprint name, and status, with an N of M count beside it. Click any column heading to sort ascending; click again for descending. The other columns follow the Display Columns list in the Settings gear; when none are ticked, Key, Summary, Assignee and Points are shown. List View has its own Create Issue button, hidden in read-only mode. The button reads Sprint View while the list is showing.

Demand by User

Demand by User — one chip per person with their remaining work and issue count
Demand by User — one chip per person with their remaining work and issue count

Appears when at least one issue has an assignee. Opens a panel headed Demand by User with one chip per person, largest first, reading for example Charlie Davis: 70 pts, 9 issues: the work not yet done that the person has across the sprints (backlog issues are not counted), sized in time projects by the project's Remaining Work setting. Clicking a chip narrows the sprint cards and the backlog on this tab to that person's issues. While a chip is chosen, each sprint header's demand is that person's work alone, but its capacity is still the whole team's, so a sprint can read Deliverable for one person that is overcommitted for the team; the card's own verdict for the team is back the moment the chip is cleared. Clicking the same chip again clears the filter. The filter applies to this tab only.

Velocity

Velocity panel — five summary cards plus sprint history table
Velocity panel — five summary cards plus sprint history table

Opens an inline panel headed Velocity containing:

Auto-Level (split button)

Auto-Level menu — Priority / Size / Due Date / Balanced, the Horizon dropdown, Include backlog issues, and Compare All
Auto-Level menu — Priority / Size / Due Date / Balanced, the Horizon dropdown, Include backlog issues, and Compare All

Both halves of the button — Auto-Level and the ▼ beside it — open the strategy menu. Choosing a strategy starts the rebalance:

The same menu also offers:

Selecting a strategy immediately runs a dry-run preview without touching Jira. While a preview is running the button reads Leveling... and afterwards carries the chosen strategy's name. Selecting a different strategy mid-session swaps the preview to the new arrangement.

Closed Sprints dropdown

A dropdown reading Closed Sprints: Hidden, with four explicit modes for showing historical sprints:

Closed sprints render inline, interleaved chronologically with active and future sprints by start date (a closed sprint that ran in February sits above an active sprint that started in March, which sits above an April future sprint). A Closed sprints divider with the number of closed sprints shown sits above the first closed sprint in the list. The dropdown only caps how many of the most-recent closed sprints are shown; their position in the list comes from their dates.

Create sprint

A button on the search row, beside Create Issue, at the right. Neither is filled blue: they are available, not urged (Don, 2026-08-20). Hidden in read-only mode. Opens a dialog headed Create New Sprint that creates a new sprint on the configured board with Sprint Name (required), Start Date, End Date, and Goal, and a Create Sprint button.

A big board arrives in more than one call

A board with thousands of issues no longer fails to load. The app reads it in calls of up to 18 seconds each, draws the cards with what has arrived, and asks for the rest until the whole board is in. While that is happening a line above the cards reads Showing 2,400 of about 3,100 issues; the rest are still loading. (the second figure is Jira's own count for the project's Issue filter; without it the line reads Showing 2,400 issues so far; the rest are still loading.). The same line appears on the Dashboard, the Scope tab and the Trends tab. Only when a single page of issues cannot be read inside the limit does the line change, in red, to the message asking you to narrow the project's Issue filter on the Projects tab; the issues already read stay on the cards.

Auto-Level session

Active sprint card with its header (the Overcommitted badge, Remaining demand, Remaining capacity, Progress and Scope change), the Sprint and Status buttons, Sync due dates, Complete sprint, the goal, the issue table, and the folded Team & Capacity line
Active sprint card with its header (the Overcommitted badge, Remaining demand, Remaining capacity, Progress and Scope change), the Sprint and Status buttons, Sync due dates, Complete sprint, the goal, the issue table, and the folded Team & Capacity line

When Auto-Level is active, a panel opens beneath the toolbar:

During a session, drag-drops between rows are local previews only — they do not write to Jira until the planner clicks Accept. The same holds for a cell edited in the issue table during a session (points, a date, an assignee, a priority, a summary): the preview shows the new value at once, nothing is written, Accept writes the held edits after the moves (the notice then reads Saved: N issues moved in Jira, M edits written), and Exit drops them with the session. An edit Jira refuses at Accept stays on the preview and is named with Jira's reason, like a refused move.

Accept sends the moves to Jira one by one. When every move lands, the notice reads Saved: N issues moved in Jira and the session ends. When Jira refuses one or more of them, the session stays open: the moves Jira took are kept, the refused issues stay where the preview put them on the cards, and a red notice reads 2 of 3 moves saved. Jira refused IBTW-5: <Jira's reason>. The refused move is still on the cards: press Accept to try again, or move it by hand. The notice stays until the next action, and a second Accept sends only the moves Jira has not taken.

Sprint row

Every sprint, the backlog, and the virtual “Oversized Issues” row (when shown) renders as a sprint card with the same structure. When the board has no sprints and the backlog is empty, the tab shows No sprints found with No active or future sprints found for this board. beneath it instead.

Header (always visible)

Header stats (not shown for the backlog; the oversized row shows a compact "N pts total · No capacity" line instead):

Closed sprints as they show with Closed Sprints set to Last 5 — each header reads Committed and Done, with a muted Delivered badge
Closed sprints as they show with Closed Sprints set to Last 5 — each header reads Committed and Done, with a muted Delivered badge

When the row is collapsed, the row beneath the header is hidden; the stats remain shown.

Actions row

Visible when the row is expanded; not shown on the backlog or the oversized row. Left to right:

Sync due dates, Start sprint, Complete sprint and Delete Sprint are hidden during an Auto-Level session.

Sprint and Status / Retro modes

Every non-backlog row has a two-button selector at the left of the actions row. The Sprint button shows the planning body. The second button is state-aware:

Sprint mode body

Visible when the row is expanded and Sprint mode is selected. The issue table comes first; the Team & Capacity section follows it.

Issue table

Inline cell editing

Editable cells show a pointer or text cursor on hover and a Click to … tooltip. There is no dashed underline: a dotted line under every editable value read as clutter (Don, 2026-08-23). The points and original-estimate cells have a minimum width so cells that display 0, -, or an empty value are still easy to hit. In read-only mode the cells stop offering an edit at all, rather than opening an input and then refusing the save.

Team & Capacity (collapsible, closed when the row opens)

The section sits below the issue table and starts closed (Don, 2026-08-20), showing one line: Team & Capacity with N pts capacity · M pts demand. Its own arrow opens it.

Changing the Capacity source clears any number typed for that sprint. When there is no capacity to show, a line beside the figure says which of three things is missing and where to fix it: the sprint has no start and end date, nobody has been added on the Team & Capacity tab, or the people there have no capacity typed. A capacity of zero somebody typed on purpose is a real answer and says nothing. The header row carries the same in a few words. On Sprint Capacity, when the people below add up to a different number, the row also says (people add up to N pts), so the two figures are never confused. On Team capacity and Effective team capacity, nobody entered on the Team & Capacity tab means the sprint reads zero — the project's number is never substituted. When people are set up on the Team & Capacity tab but none has a share of this project, an amber notice says so and points to the Team Allocation Matrix on the Projects tab.

Status and Retro mode body

Visible when the row is expanded and the second mode button is selected — Status on a future or active sprint (what has happened so far) or Retro on a closed sprint (the final review). The header line reads Sprint Status or Sprint Retro, names the sprint beside it with Not started, Active or Completed, and carries the Export button, which copies the review — title, summary, the metrics table and the action items with their owners and tick state — to the clipboard as text ready to paste into a retro write-up; it reads Copied! once the copy has worked. There is no separate sprint dropdown — the row you expanded is the sprint. On a future or active sprint the three sections that only make sense once the sprint closes — Team Health Pulse, Insights and Talking Points — are held back behind a padlock reading Unlocks when the sprint closes, and the notice above the sections names them.

This view reads the same sprint and velocity data the rest of the app uses, so its numbers match the sprint stats above and the Dashboard. It turns a sprint into a structured review for the scrum master or team lead: what was committed versus delivered, what slipped, the patterns behind it, and a set of follow-up actions.

The sections appear in this order, each folding open and closed from its heading: Sprint Summary, Delivery Metrics, Team Health Pulse, Patterns, Insights, Talking Points, Team Contribution, Action Items. Sprint Summary and Delivery Metrics start open; the rest start closed.

One size for an issue, in this whole view. Delivery Metrics, Team Contribution, Team Health Pulse and the Flag button all size an issue the same way: an unfinished issue by the project's Remaining Work setting in the Projects tab's Add / Edit Project form (Committed size by default, or Live estimate), a finished issue always at its committed size. The real values are added up and rounded once, where the figure is shown, to one decimal — so four half-hour tasks read 2 hrs in every section and a twenty-minute task reads 0.3 hrs rather than vanishing or being called unestimated. Only an issue with no estimate at all is an estimation gap.

Sprint Summary

A plain-language recap: how much was delivered of what was planned and the completion rate, how many issues and points carried over, and how many were added mid-sprint. On a closed sprint it ends with a one-line verdict (for example Overall, the sprint was successful. at 85% or more). It is the one-paragraph “what happened.”

Delivery Metrics

The same figures as a table — Planned, Delivered, Carry-over, Scope Added, and Completion Rate — with an average column alongside, so the sprint reads against its recent baseline. In the Status view three rows are renamed for a sprint that has not finished: Completed so far, Remaining and Completion so far.

The average is the three sprints that closed before the one you opened, in date order — never the sprint itself, and never a sprint that came after it. Every closed sprint the board holds is history (26 September 2026): the sprints the app closed itself, whose figures it captured at the time, and every other closed sprint read from Jira, counted the same way as the header's Committed and Done (work carried out of a sprint is planned there, not delivered there). Until then the average knew only the sprints the app had closed, so a project closed in Jira compared against nothing. Where fewer than three closed before it, the column heading names how many it used (2-Sprint Avg, 1-Sprint Avg); where none did, it reads No history and its cells show a dash. Only Planned and Delivered have an average; the other three rows show a dash. The Trend column compares the sprint with that average. Delivering more than the average is shown in green and less in red; planning more than the average is shown in the warning colour, because planning more than usual is what this product exists to warn about.

Note the deliberate difference from the header: Planned counts every issue in the sprint including finished ones (the committed size), while the header's Demand counts only unfinished work (what still needs capacity) — the two answer different questions and are not meant to match. When a closed sprint still has unfinished work and a sprint that is not closed exists, a 📌 Flag N issues for [next sprint] button appears here, with Surfaces in [next sprint]'s Risk analysis beside it; clicking it surfaces those carry-over issues in that sprint's Confidence panel, each recorded at its size in the project's own unit.

Team Health Pulse

An overall health percentage plus three scored dimensions — Commitment vs Delivery, Scope Stability, and Estimation Quality — a quick read on how the sprint went beyond the raw totals. Shown on a closed sprint's Retro only: on the Status view it is held back behind the padlock like Insights and Talking Points, because Commitment vs Delivery is the completion rate plus ten, which would score a sprint nobody has worked on yet as a failure. The same figure, sized the same way, is what the Risks tab's Suggested by the app list reads when it offers a team health declining risk.

Patterns

Observations the app raises automatically from the data, each with a short, specific note and the issue keys behind it: Carry-over (closed sprints), Mid-sprint Scope Growth, Estimation Gaps, Below Target Completion (a closed sprint under 80%), and Clean Sprint (a closed sprint with no carry-over, no additions and 80% or more completion).

Insights

Cards drawn from the metrics — Root Cause (a completion rate under 85% suggesting over-commitment), Pattern (two or more mid-sprint additions, suggesting a buffer), Positive (delivered more than 10% above the average, shown only once there is an average to be above), and a Recommendation card suggesting the next sprint's commitment: 95% of the average delivered over the sprints that closed before this one, worded on screen as (95% of your recent average velocity — a small buffer for reliability). When no sprint has closed yet, the Recommendation names the project's Sprint Capacity from the Projects tab's Edit Project form as the figure to plan against and says that is why; when that is not set either, it says what to set.

The Insights are worked out from the sprint's own figures — the completion rate, mid-sprint additions, the recent average, the project's Sprint Capacity — so they are the same every time and need no AI. Until 18 September 2026 an AI Insights button here sent those metrics to an AI provider and printed the paragraph it wrote back, with a follow-up chat beneath it. Don had both removed: their wording and their numbers were the model's.

Talking Points

Numbered discussion prompts for the retro meeting, drawn from the sprint's specifics. Locked on the Status view, since they only make sense once the sprint has closed.

Team Contribution

Headed Not a leaderboard: a per-member breakdown of completed against committed work for each active person on the Team & Capacity tab who has work in the sprint, with a % blocked flag at 20% or more, trend arrows for people with three or more sprints of history, and an Anonymize checkbox for sharing the retro outside the team.

Action Items

A register of follow-up actions, each with an owner and a done or open status. Add an item (Action item... and Owner boxes, then Add), tick it done, or delete it with ✕. The heading shows N of M complete. Action items persist with the sprint and also appear, globally, on the Actions tab. (Carrying unfinished work into the next sprint is done from the Delivery Metrics section's Flag … issues button, not here.)

Complete-Sprint dialog

Opens when an active sprint is being completed and there are incomplete issues, open action items, or risks whose mitigation is fully done. Headed Complete Sprint: <name>. Sections shown as needed:

Complete Sprint carries out the action-item choices, the risk closures, the issue moves (or sprint creation and move), and finally completes the sprint. The view refreshes on success.

Delete-Sprint dialog

Future sprints with issues open a dialog headed Delete Sprint: <name> with a destination — Move to Backlog or Move to Sprint: another sprint. Delete Sprint moves the issues, then deletes the sprint. Future sprints with no issues just show a plain confirm.

Above the sprint list. The planner can type a JQL query in the box (Search issues (JQL) — e.g. assignee = currentUser() AND status != Done) and press Enter or click Search. Results appear in a panel headed N results with a Collapse link, as a table of key (a link), summary, assignee, size, and status, capped at fifty rows. No issues match the query. when nothing matches; once collapsed, Show N search results opens the panel again. Clear resets the search.

A Create Issue button sits at the right end of the row, after Create sprint (hidden in read-only mode and in demo mode). It opens a panel headed Create issue with a Project dropdown, an Issue type dropdown (Story, Task, Bug, Epic), a Summary box, and Create or Cancel. The issue is created in the backlog, and the panel confirms with Created <key> in the backlog. or shows the error.

Backlog row

Sits below the sprints. Same card structure but with no header stats, no actions row, no mode selector, and no Team & Capacity section — the header reads Backlog with the issue count beside it ("8 issues"), then the issue table, with a + Create Issue button at its foot (hidden in read-only mode and in demo mode). It always lists every issue in the backlog, whether or not Include backlog is ticked — that checkbox only decides whether backlog work counts in the numbers. When empty, the backlog shows a drop area reading Backlog and Drop issues here to move to backlog, so issues can still be dragged in.

Oversized Issues row

A virtual row that appears at the bottom of the sprint list during Auto-Level when Auto-Level could not place one or more issues. It is named Oversized Issues when every one is larger than any sprint's capacity, otherwise Unplaced Issues, and its badge gives the issue count. Capacity controls and drops onto it are disabled. A banner explains the problem, says that Backlog is recommended, and — for unplaced issues — suggests widening the horizon under Auto-Level ▾. The planner picks a destination for each issue at Accept time.

Cross-cutting modes and settings

How the numbers are computed

Effects on other parts of the app

© 2026 Project Commander · projectcommander.app · Support · Privacy · Security · Terms