Documentation

Realistic sprint commitment, live risk detection, and a per-person forecast — from the data already in your Jira board.

What it does

The App answers three questions a Scrum board on its own cannot:

• How much can this team really take on? Effective capacity from sprint dates, working days, hours per day, time off, holidays, focus factor and allocation — per person, not a single team number.
• Is the running sprint in trouble? A 0–100 health score broken into pace, capacity, scope, blockers, execution and data quality, with the required pace to finish and a spillover range with confidence.
• Whose work will not land? A per-person forecast that samples each member's own past throughput against the hours they have left, and names the items most likely to spill.

Every figure is arithmetic on your Jira data and the availability your team enters. There is no AI, and every number can be traced back to what produced it.

Installation

1. Install from the Atlassian Marketplace, or from Apps › Find new apps inside Jira. A Jira site administrator must do this.
2. Open any Scrum project. Sprint Capacity Planning & Forecast appears in the project sidebar.
3. The first time it opens in a project, the setup wizard runs. It takes about two minutes.

Setup wizard

Installing the App tells Jira nothing about how your team plans, so four questions are asked once per project. Setup in the top bar reopens the wizard at any time.

1. Board. Which Scrum board holds this project's sprints. Jira gives the App a project but never a board, and without one there are no real sprints to read.
2. Story points. Which numeric custom field holds them. The field ID differs on every Jira site. Until chosen, the App falls back to the first numeric custom field it finds — which can just as easily be business value, so choose it.
3. Team. Everyone Jira reports as assignable, each assumed full-time at 8 hours a day with a 0.7 focus factor. Correct part-time and off-team people here before any capacity number is drawn from them.
4. Ready. A plain statement of the cold start — see below.

The cold start

With no completed sprints, the App has nothing to learn from. Until one sprint closes:

• Team capacity stands in as whatever is already committed, so utilisation reads near 100% regardless of what the team took on.
• The per-person forecast stays unavailable. It needs at least one finished sprint per person to sample from.

The App says this on screen rather than showing numbers that look like findings. Both become real the first time a sprint is completed from the App's toolbar.

Screens

Plan

The sprint being planned, as a board, list or per-person groups. Each person's row shows effective capacity against assigned work. Drag to reassign; edit summary, estimate, status and sprint inline; create items directly into a sprint column, the list, or a person's group. Changes are written back to Jira — nothing lives only in the App.

Monitor

The running sprint's health score and its six factors, burndown with projection, required pace, scope changes since baseline (added, removed, estimate changes, net and gross), issue-level risk flags, and ranked spillover candidates.

Forecast

Per person: probability of clearing their queue, the spillover range at P50 and P90, and which of their items are most at risk. Work is counted per item, not per point — a task is finished or it is not. What-if changes can be simulated locally before applying them to Jira.

History

Every completed sprint: committed versus completed, scope change, spillover, velocity, and predictability trend.

Admin

Team roster, availability, holidays, working days, planning mode (story points or hours), thresholds, and the audit log of configuration changes.

Baselines

A baseline is a snapshot of what the sprint contained when it started — the committed scope everything after is measured against. The App takes one when you start a sprint from its toolbar. If a sprint is already running when the App first sees it, the baseline is marked Late: the numbers before that moment were never captured, and the scope metrics say so. Re-baselining asks for a reason, which is recorded in the audit log.

Starting and completing sprints

The toolbar button follows the sprint: Start sprint while it is planned, Complete sprint once it is running.

• Start asks for name, duration, dates and goal, writes them to Jira, and takes the baseline.
• Complete moves unfinished work to the next sprint or the backlog, closes the sprint in Jira, and records the result as history — which is what velocity, confidence and the forecast learn from.

Jira exposes no native start- or complete-sprint dialog to apps, so these are the App's own dialogs around the same questions and the same writes. A completed sprint cannot be reopened from the App.

How writes reach Jira

The App keeps no copy of your work items. Field edits go through Jira's issue API, status changes through the workflow transition that leads to the target status, and sprint moves through the Agile API — always as you, with your permissions. Edits are batched per item and flushed shortly after your last change, or immediately if you leave the page. If Jira rejects a write, a banner says the change is not saved rather than leaving a screen that looks right until it reloads.

Pricing and licensing

• Free for Jira sites with up to 10 users.
• Larger sites get a 30-day trial that rolls into a paid subscription unless cancelled from Apps › Manage apps.
• If a subscription lapses, everything stays readable but changes stop saving to Jira until it is renewed. Nothing is deleted.

Permissions

The App requests the Jira scopes needed to read boards, sprints, work items and assignable users, and to write item fields, transitions, sprint membership and sprint state — all exercised as the signed-in user. It stores its configuration in Atlassian-hosted storage and makes no requests outside Atlassian. See the Privacy Policy.

Frequently asked questions

Utilisation says 100% for every sprint.

No sprint has been completed from the App yet, so capacity is standing in as committed work. Complete one sprint from the toolbar.

The forecast says "unavailable".

Same cause. It needs a completed sprint per person to sample from.

Story points are showing the wrong numbers.

The wrong field was picked in setup, or none was. Open Setup and choose the field your board actually estimates with.

Someone is on the team who should not be.

The roster is everyone Jira reports as assignable. Set their allocation to 0% in Setup or Admin, or remove them from the roster.

Avatars show initials instead of pictures.

Profile pictures load from Atlassian's own avatar servers. If a corporate proxy or browser extension blocks them, initials are shown instead. Nothing else is affected.

Can I use hours instead of story points?

Yes — planning mode is in Admin. Hours use Jira's remaining time estimate on each item, so they fall as work is logged.

Trying it out

To see the App with real numbers rather than the cold start, on a test project:

1. Create a Scrum project with a board and a story-points field, and a handful of estimated, assigned issues.
2. Open the App, run setup, and pick that board and field.
3. Move a few issues into a sprint on the Plan screen and press Start sprint.
4. Transition some issues to Done in Jira, then press Complete sprint.
5. History, real capacity, and the per-person forecast are now live for the next sprint.