Sprints Tab — Feature Guide

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:

• See commitment versus capacity for every active and future sprint at a glance.
• Drag work between sprints and into or out of the backlog.
• Lock issues or whole sprints in place.
• Run automated rebalancing across sprints.
• Start, complete, and delete sprints, including roll-over of unfinished work.
• Switch any row between a forward-looking Sprint view and a Status or Retro view.

The tab is strictly per-project. In “All projects” mode it is replaced with a notice asking the user to pick a single project, because sprint cadences from different projects cannot be summed.

Toolbar

A single row at the top of the tab. Left to right:

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 every sprint plus the backlog. Search filters across key, summary, assignee, sprint name, and status. Click any column heading to sort ascending; click again for descending. Visible columns follow the project’s configured columns.

Demand by User

Appears when at least one issue has an assignee. Opens a panel of clickable user chips showing the user’s name, total demand, and issue count. Clicking a chip filters the rest of the application to that user. Clicking the same chip again clears the filter.

Velocity

Opens an inline panel containing:

• Five summary cards: average velocity, effective capacity, points per week, efficiency, and completion percentage. The effective-capacity card normally reads sprint capacity × measured efficiency; when no efficiency has been measured it falls back to average-per-week × sprint length and says so on the card ("avg/week × weeks — no measured efficiency").
• A sprint-history table for closed sprints with length, capacity, completed, points per week, efficiency, and effective capacity. Each row expands to a per-issue table (status, key, summary, assignee, points, and flags) for that sprint; per-member figures come from the filter chips, not the row expansion.
• Filter chips to view metrics for the whole team or one team member.
• Reload Velocity (refetches the latest history from Jira) and Clear History buttons.
• A Lookback dropdown — Last 3, 5, 8, or 10 sprints — that is shared across every tab.
• An Import from Completed Sprints action that appears only in the empty state (when there is no velocity data yet) for bringing in historical velocity data. The outcome is shown next to the button after the click — a green "Imported N sprint(s)" on success, or a red "Import failed: …" with the reason.

Auto-Level (split button)

Main button starts the rebalance; the chevron opens a strategy menu:

• Priority — fills sprints front to back with highest-priority issues first.
• Size — fills sprints front to back with smallest issues first.
• Due Date — fills sprints front to back with soonest-due issues first.
• Balanced — places the largest issues first into the sprint where they fit best, balancing remaining room and workload.

The same menu also offers:

• Horizon — a dropdown limiting how far ahead Auto-Level rearranges: Next sprint, Next 2 sprints, Next 3 sprints, or All sprints.
• Include backlog issues — a checkbox that controls whether backlog work counts in the numbers — Auto-Level, the Dashboard, Scope, What-If and the alerts. The Backlog card at the foot of this tab lists what is in the backlog whether or not this is ticked.
• Compare All — runs all four strategies in parallel and shows a side-by-side delivery forecast so the planner can pick the best plan.

Selecting a strategy immediately runs a dry-run preview without touching Jira. 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:

• Hidden — no closed sprints (the default; fastest).
• Last 5 — the five most-recent closed sprints, sorted by end date.
• Last 20 — the twenty most-recent closed sprints.
• All — every closed sprint available.

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). The chip just caps how many of the most-recent closed sprints are loaded; 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 that creates a new sprint on the configured board with a chosen name, start date, end date, and goal.

Auto-Level session

When Auto-Level is active, the toolbar expands with a session panel:

• Moved issues are flagged inline rather than via a legend: each moved row carries an Auto-levelled or Manually moved badge, and locked issues show a lock icon — so the planner can tell why each issue ended up where it did. (There is also a Deviations summary line noting whether the strategy could place every issue as preferred, or counts of what was constrained by capacity, dependencies, due dates, locks, or the horizon.)
• Balance Preview — lists the first twenty proposed moves (issue, summary, from sprint → to sprint, points), with overflow shown as “…and N more”. Apply commits the moves; Cancel exits.
• No-capacity warning when there is no closed-sprint history and nobody on the Team & Capacity tab, naming what Auto-Level packs against instead: the project's Sprint Capacity number from Projects → Edit.
• Forecast pill — projected on-time percentage with P50 and P85 sprint estimates, coloured green, amber, or red.
• Skill mismatch panel — when team skills are configured, surfaces per-sprint counts of issues whose assignee lacks required skills. Hover lists the issues and missing skills.
• AI Review — when an AI key is configured, asks the AI to review the staged plan for dependency issues, overloaded developers, and capacity concerns. Returns a one-sentence summary, per-sprint findings, and recommendations.
• Action buttons — Undo Changes (reverts to the original arrangement, stays in session), Accept (commits to Jira), AI Review, and Exit (cancels the session entirely).
• Delivery Forecast comparison — appears when Compare All is on, showing all four strategies side by side.
• Oversized Placement dialog — appears at Accept time when one or more issues are larger than every sprint’s capacity. Each oversized issue gets its own destination dropdown (Backlog is recommended, but any open sprint can be picked).

During a session, drag-drops between rows are local previews only — they do not write to Jira until the planner clicks Accept. Moved issues are tagged with a small badge showing where they came from and are sorted to the top of each sprint so they are easy to spot.

Sprint row

Every sprint, the backlog, and the virtual “Oversized Issues” row (when shown) renders as a sprint card with the same structure.

Header (always visible)

• Drag handle for reordering sprints up or down. The order is remembered.
• Collapse/expand chevron — per-sprint open/closed state is remembered.
• Sprint lock — pins every issue in this sprint during Auto-Level. Locked sprints also reject drops.
• Sprint name plus a state badge (Active, Future, or Closed).
• Clickable date range. Click to inline-edit the start and end dates; “No dates set” appears when missing.

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

• Deliverability badge — Deliverable, Tight, or Overcommitted on active and future sprints. A CLOSED sprint's badge says what happened instead (2026-09-02): Delivered, in muted grey-blue, only when everything it committed was finished; otherwise Delivered M of N (done of committed) in muted amber — colours distinct from the forward-looking trio, so a past sprint never reads as a live verdict. The badge is a direct demand-versus-capacity check, so it always matches the demand and capacity figures shown beside it — on first render, after a drag-drop, and after an Auto-Level session. For an active sprint it answers "does the remaining work fit the capacity left in this sprint?" — see the Remaining demand / Remaining capacity stats below. Forward-looking pre-mortem confidence is shown in the Risks modal instead (see below), not in this badge.

• Confidence button (future and active sprints) — opens a modal with the confidence score, the risk factors and a suggested trim list of issues to defer. On an active sprint (added 2026-09-02) it judges the rest of the sprint: the remaining demand against the capacity left, with velocity scaled to the part of the sprint still ahead, and the modal's figures read Remaining and Capacity left instead of Committed and Capacity; work in progress is not counted as carry-over mid-sprint. Closed sprints have no button — nothing is ahead of them; Retro is their view.

• Demand — total work to deliver, in points, hours, or days. On an ACTIVE sprint the stat is labelled Remaining demand and counts only work not yet done.
• Capacity — this sprint’s capacity, from whatever its Capacity source control is set to. On an ACTIVE sprint the stat is labelled Remaining capacity: the effective limit scaled to the fraction of the sprint's calendar duration still ahead of today (a 36-pt sprint at its halfway point shows 18). A sprint Jira still marks future whose dates have already passed is treated the same way and reads Remaining capacity 0 — it was never started and its days are gone (decision 2026-09-03) — so its badge judges its demand against nothing rather than against a full figure the days can no longer supply. Days already elapsed were spent on the work that is now done, so remaining work is judged against remaining time — a sprint can no longer read Deliverable on its last day just because its full-sprint capacity exceeds the open work. Sprints without dates can't be prorated and show the full limit; each active sprint (including parallel active sprints) is prorated by its own dates. The editable capacity value in the Team & Capacity section below stays the full configured limit — it is the setting, not the measurement.
• Progress (active sprints) — the share of the sprint's committed work already burned down. Mode is configurable: by points, by remaining estimate, or by work ratio (time spent versus time spent plus remaining).
• Load (future sprints) — demand as a share of the sprint's capacity, where 100% exactly fills it, shown in red above 100%. It comes from the same shared definition the deliverability badge beside it uses, so the two can never disagree. A future sprint has no burn-down to report, and Progress — told the reader nothing.

• Committed · Done (closed sprints) — a closed sprint's header carries these two figures in place of Demand, Capacity and Load (2026-09-02): Committed is every issue at its full size (cancelled work excluded) and Done is what was finished, both summed from the same per-person Committed and Completed figures the Team & Capacity table below shows. The old header read Demand 0 pts · Capacity N · Load 0% on every closed sprint and looked like a fault.
• Scope — scope ADDED since the sprint started, the same measure as the Status section's Scope Added: work pulled into the sprint after start, estimate increases, and issues created after start, read from each issue's Jira change history. When no change history is available it falls back to a start-of-sprint snapshot (demo data) or to issues created after start. Future sprints and the backlog show — (nothing can be "added" before a sprint starts). Red when positive, green when negative.

When the row is collapsed, the action buttons are hidden; the stats remain shown.

Action buttons (right-aligned, hidden during Auto-Level and when the row is collapsed):

• Sync due dates — pushes the sprint's end date to every issue's due date. Disabled when the sprint has no issues or no dates. Reports per-issue success and failure inline.
• Start sprint (future only) — confirms with an explicit warning if another sprint is already active. Not filled blue: starting a sprint is a choice, not the thing the screen is pushing you towards (Don, 2026-08-20).
• Complete sprint (active only) — opens the Complete-Sprint modal when there are incomplete issues, open action items, or risks ready to close. Otherwise a simple confirm.
• Delete Sprint (future only) — opens a destination picker if the sprint contains issues, otherwise a plain confirm.

Sprint and Status / Retro modes

Every non-backlog row has a two-button selector under the header. The sprint goal sits on the same row, to the right of the selector — click the goal text to inline-edit (Save or Cancel); because this row is shown in every mode, the goal stays visible in Sprint, Status, and Retro views. The Sprint button shows the planning body. The second button is state-aware:

• Future sprint — labelled “Status”, shows live progress for any work already underway.
• Active sprint — labelled “Status”, shows live actuals and projected metrics.
• Closed sprint — labelled “Retro”, opens the post-sprint retrospective. Closed rows default to this view.

Sprint mode body

Visible when the row is expanded and Sprint mode is selected.

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

• Full capacity row — labelled Full capacity: shows this sprint's capacity. Click the value to type a number for this sprint alone. On an ACTIVE sprint a read-only Remaining capacity figure sits beside the control — the full capacity scaled to the sprint's remaining days, the same number the header stats and badge use. Beside it, a control labelled Capacity source with three choices:

• Sprint Capacity — the project's number from the Projects → Edit form, or a number typed for this sprint by clicking the figure. (Until 2026-09-01 these were two separate choices, Project default and Custom, which were the same thing.)
• Team capacity — everyone marked active on the Team & Capacity tab who has a share of this project, added up. A number typed for one person in the table below replaces what that tab works out for them, and moves this sprint's figure and its badge with it.
• Effective team capacity (N%) — the same sum multiplied by historical efficiency, which is finished work divided by committed work averaged over closed sprints. The option is listed when a closed sprint gives a usable reading, or when it is already selected; if there is no usable reading, the option and the header equation both read "(80% assumed)" so the standard-assumption fallback is never mistaken for a measurement.

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. When the sprint carries a number of its own, the row also states what the people below add up to, 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.

• Per-member table — one row per assignee with Member, Total Demand, Completed, Capacity, and Status. The Capacity cell is that person's own capacity — the number typed for them here if there is one, else what the Team & Capacity tab works out for them. It is never a share of the sprint's own number, which is what it was on some sources until 2026-09-01. On an ACTIVE sprint the capacity pair is Full Capacity (editable) and Remaining Capacity (read-only — the full value scaled to the sprint's remaining days); future sprints show the single Capacity column.

• Click a row to filter the table to just that user; click again or hit Show All to clear.
• A small “N blocked” badge appears when an assignee has blocked work.
• Capacity is editable inline: the number is that person's capacity for that sprint, and it is written to their weekly values on the Team & Capacity tab — the same place that tab's Sprint period sets. Right-click clears it, putting the person back on whatever they had before. Since both screens write there, a number set on either shows on the other, and on Team capacity it moves the sprint's own figure and its badge.
• Status badge per member uses the shared load bands: OVERLOADED (> 115% of capacity), OPTIMAL (90–115%), AVAILABLE (60–90%), UNDERLOADED (< 60%) — the same bands as the Team & Capacity tab. On an ACTIVE sprint the band compares the member's remaining work against their capacity scaled to the sprint's remaining days (same rule as the header's Remaining capacity); the editable Capacity cell still shows the full per-sprint value.

Issue table

• Columns are dynamic — Key and Summary always show; Assignee, Points (or Hours/Days), Remaining Estimate, Original Estimate, Time Spent, Status, Type, Priority, Start Date, and Due Date can be enabled in project settings.
• Click any column header to sort ascending, again for descending, again to clear.
• Bulk select via header and per-row checkboxes. Selecting one or more issues opens a sticky toolbar at the top with: count of selected, Move to backlog, Set priority (Highest, High, Medium, Low, Lowest), and Clear.
• Drag any row to another sprint to move it. If the dragged row is part of a multi-select, the whole selection moves together. Drop on another row in the same sprint to reorder. Drop on the backlog area to move to backlog. Locked issues are filtered out of any drop. Auto-scroll kicks in near the top and bottom of the viewport during a drag.

Inline cell editing

Editable cells show a text cursor on hover and a Click to edit … tooltip. There is no dashed underline: a dotted line under every editable value read as clutter (Don, 2026-08-23). The click target has 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.

• Key — opens the issue in Jira. A warning icon appears when the issue is blocked by something in a later sprint.
• Summary — click to edit text. Enter saves; Escape cancels.
• Assignee — click to open a dropdown of the active team members plus Unassigned. The dropdown floats above the table on a portal layer so it is never clipped by row or table overflow. Optimistic update with rollback on error.
• Story points — click to edit (points mode only). Zero-valued and unestimated cells have the same enlarged hit target.
• Original Estimate — click to edit (time mode only; column header reads Time (hrs) or Time (days)). Zero-valued cells are clickable.
• Status — click to open a transition list fetched live from Jira; No transitions available when none apply.
• Priority — click to choose from the five-level palette with coloured dots.
• Due date — click to open a date picker; past-due dates are highlighted on non-done issues.
• Time Spent and Remaining Estimate are read-only and formatted in hours or days.
• A warning icon appears in points, original-estimate, or remaining-estimate cells when an issue is larger than the sprint’s capacity.

• A per-row lock button keeps that issue in place during Auto-Level. During a session, moved issues show a small “← FromSprint” badge.

Quick Create issue

A “+ Create issue” link at the bottom of each sprint expands into a small form with an issue type dropdown (Story, Task, Bug, Sub-task), a summary input, and Add or Cancel. Hidden in read-only mode.

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 (a live, in-progress preview) or Retro on a closed sprint (the final review). The sprint's name shows above the review; there is no separate sprint dropdown — the row you expanded is the sprint. On an active sprint the sections that only make sense once the sprint closes — Talking Points, and parts of Insights — are locked until it ends.

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.

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. It is the one-paragraph “what happened.”

Delivery Metrics

The same figures as a table — Planned, Delivered, Carry-over, Scope Added, and Completion Rate — each with the team's three-sprint average in a column alongside, so the sprint reads against its recent baseline. 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 next sprint exists, a Flag N issues for [next sprint] button appears here; clicking it surfaces those carry-over issues in that next sprint's Risk analysis.

Patterns

Observations the app raises automatically from the data — for example a clean sprint (no carry-over, no additions, good completion), a below-target completion rate, or recurring mid-sprint scope additions — each with a short, specific note.

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.

Team Contribution

A per-member breakdown of who delivered what, with an Anonymize toggle for sharing the retro outside the team.

Insights

Two layers. First, deterministic insight cards drawn from the metrics — over-commitment, a buffer for recurring scope additions, an upward velocity trend, and a suggested next-sprint commitment of 95% of the team's recent three-sprint average delivered, shown labelled (P85 of recent velocity).

Then, when an AI provider and key are configured in Settings, an AI Insights button generates a short narrative analysis of the sprint from the same metrics. Below that summary is a follow-up chat: ask a question about the retro and it answers in a thread, carrying the conversation so each follow-up builds on the last answer. The conversation clears when you switch to a different sprint.

Talking Points

Discussion prompts for the retro meeting, drawn from the sprint's specifics. Locked during an active-sprint live preview, since they only make sense once the sprint has closed.

Action Items

A register of follow-up actions, each with an owner and a done or open status. Add an item, mark it done, or delete it. 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 modal

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

• Incomplete issues — choose Backlog (the default), one of the existing other sprints (each shown with its current points total), or Create new sprint.
• Closeable risks — one checkbox per risk whose mitigation actions are all complete; tick to mark closed on confirm.
• Open action items — per-item radio with three choices: roll over to a chosen future sprint, mark done, or leave on this sprint. A “Roll all over” bulk control with a destination picker and Apply appears when there is more than one item.

Confirm executes the action-item dispositions, the risk closures, the issue moves (or sprint creation and move), and finally completes the sprint. The view refreshes on success.

Delete-Sprint modal

Future sprints with issues open a destination picker — Backlog or another sprint. Confirm moves issues, then deletes the sprint. Future sprints with no issues just show a plain confirm.

JQL Search

Above the sprint list. The planner can type a JQL query and press Enter or click Search. Results appear in a collapsible table (key with link, summary, assignee, points, status badge), capped at fifty rows. Clear resets the search.

A persistent Create Issue button sits at the right end of the row (hidden in read-only). It opens a popover with a project dropdown, an issue type dropdown, a summary input, and inline success or error feedback.

Backlog row

Sits below the sprints. Same card structure but with no header stats, no actions, no mode selector, and no per-user table — the header reads Backlog with the issue count beside it ("8 issues"), then the issue table. 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 renders a drop zone 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 one or more issues are larger than every sprint’s capacity. Capacity controls and drag are disabled. A banner explains that Backlog is recommended, and the planner picks a destination for each oversized issue at Accept time.

Cross-cutting modes and settings

• Estimation mode — Story Points or Time. Time mode swaps points for hours or days everywhere in the tab.
• Time unit — Hours or Days. Drives the displayed unit and the conversion of estimates.
• Capacity source — each sprint can be set to Sprint Capacity (the project's number or one typed for that sprint), Team capacity, or Effective team capacity.
• Sprint and issue order — manual reordering of sprints and of issues inside a sprint is remembered.
• Read-only mode — hides Create sprint, Quick Create, lock toggles, drag, and batch actions, and stops the issue table's cells offering an edit at all. Auto-Level still runs but Save is blocked with a “preview only” notice.
• Program-All mode — the Sprints tab is hidden in favour of a notice asking the user to pick a single project.
• Locks — per-issue and per-sprint locks are honoured by Auto-Level (locked things never move) and by drag-and-drop (locked rows can’t be dragged; locked sprints reject drops).

How the numbers are computed

• Auto-Level — walks the open sprints in order, applies the chosen strategy to order issues, places each one into the first sprint where it fits, and never exceeds capacity. The ACTIVE sprint's capacity is its remaining capacity — the effective limit scaled to the days still ahead (same rule as the header stat) — so mid-sprint the engine moves out what genuinely no longer fits. Overflow spills into proposed new sprints, capped at a safe maximum. Locked issues stay put; locked sprints are skipped.
• Effective team capacity — team capacity multiplied by the team’s historical efficiency — finished work divided by committed work, averaged over closed sprints. When no closed sprint gives a usable reading, a standard 80% is used and the header marks the percentage as "assumed".
• Calculated capacity per sprint — comes from the Team & Capacity tab and contributes total points, total hours or days, and per-member capacities.
• Sprint confidence — a Monte Carlo simulation over velocity history, with adjustments for unestimated, large, and blocked items, on future and active sprints (an active sprint on the part still ahead of it). Mapped through three confidence bands and surfaced in the per-sprint Confidence modal (it no longer drives the header deliverability badge).
• Save — compares the staged plan with the original baseline, computes the net moves, and sends them to Jira along with any newly proposed sprints. Backlog moves are sent separately.

Effects on other parts of the app

• Demand by User: selecting a user filters work everywhere via the global user filter.
• Velocity Lookback: changing it here changes it for every tab.
• Include backlog: affects Auto-Level and every other view that counts the backlog in its numbers. The Backlog card on this tab always lists the backlog regardless.
• Closing risks from the Complete-Sprint modal updates the global risk register.
• Action-item rollovers append the source sprint id to the action item so the destination shows the rollover provenance.
• Date sync writes individual issue due dates and triggers a refresh once finished.