User guide

For the people using it, not the people building it. If you're setting it up, start at First five minutes. If someone already set it up and you just want to read the numbers, skip to The overview page.

What this is for

Jira knows what work is in your sprint. It doesn't know that two people are on leave, that one is only with you three days a week, and that your tech lead never actually picks up tickets. So its board implies a team that doesn't exist.

This app puts those facts back in, then answers one question in words: is this sprint going to land?

First five minutes

Open Apps → Sprint Verdict, or the Capacity tab inside a project.

1. Check the estimation field

Go to Settings. The app guesses which field you estimate in — usually Story Points.

If the numbers look wrong, or everything reads zero, this is why. Pick the right field from the dropdown. Anything works: a custom Dev days field, a complexity score, even T-shirt sizes (you'll be asked what each size is worth).

If your team doesn't estimate at all, switch the metric to Issue count and skip this.

2. Set up your team

Go to Team.

Everyone with work in the current sprint appears automatically, marked from issues. Add anyone missing from the picker.

Then uncheck anyone who shouldn't count towards capacity — managers, contractors, people who only occasionally grab a ticket. Their work still shows on the sprint page; it just stops making the team look over-loaded.

Set allocation for part-timers. Someone at 60% has 60% of the days.

3. Connect your leave

Still on Team, find Where leave comes from.

• Already track leave in Jira? Choose Jira issues, pick the project, press Test it. Done — the app reads it and stores nothing.
• Don't? Either follow the recipe on that page to make a small Leave project (two minutes, and you get a board and approvals for free), or choose Manual only and type leave in by hand.

Add your public holidays while you're there.

Optional: pick a theme

Go to Settings → Appearance and pick one of six themes — Violet, Nord, One Dark, Solarized, Dracula or Graphite. It's yours alone: everything else on the Settings page is shared with the team, but this lives in your browser and changes nothing for anyone else.

Every theme has a light and a dark version, so the Auto / Light / Dark toggle top-right still works exactly as before. Leave it on Auto and the app follows Jira.

Green, amber and red always mean healthy, warning and over capacity. A theme adjusts those shades so they stay readable on its background, but never changes what they mean.

4. Read the verdict

Go back to Delivery trends. There's now a large number and a sentence telling you whether the sprint is on track, behind, or overcommitted, and why.

That's it. Everything else is detail behind that sentence.

The delivery trends page

Opens with the verdict strip: one big completion number, a status in words, and the single sentence explaining it.

The checks run worst-first, so the headline names the most serious problem rather than the first one it finds.

Beside it: committed, capacity, loaded, and — when it applies — not counted. That last one is work belonging to excluded people and unassigned issues. It's real work with nobody's capacity behind it, so it's shown separately rather than folded into a number it can't be divided against.

Below the verdict is the track record: velocity per sprint, completion against scope change, a heatmap of who delivered what, and a consistency score per person.

Predictability is worth understanding: it's how steady your velocity is, not how fast. A team doing 20 points every sprint scores 100%. A team alternating 5 and 40 scores badly even though it averages more. Steady is what makes planning possible.

The current sprint page

The same verdict, then the detail.

Team capacity

The table everyone actually looks at.

Over 110% is over capacity. Under 70% is under capacity. Someone away the whole sprint is away, not over — they have no capacity to be over.

People on the roster with nothing assigned still get a row. An idle person is exactly what a capacity view should surface.

Away this sprint

Everyone off during the sprint, and for how long. Rows read from Jira link back to the issue, so the reason is always one click away.

Burndown

Dashed is the ideal line, solid is what happened. It's built from the real status-change history, not from resolution dates, so it reflects when work actually finished.

Planning

Three questions, in the order a refinement meeting asks them.

What fits in the next sprint

Walks your backlog in Jira's rank order and takes items until capacity runs out. It deliberately doesn't reorder to pack the sprint tighter — that order is your priority call, not the app's.

It names the first item below the line, which is usually the thing worth arguing about.

Runway

How many sprints of backlog you have left, as three bands: your fastest, average and slowest recent sprints. A range, not a date.

It assumes nothing new arrives, which is never true. Read it as "if we stopped adding things", and read the scope-change trend on the Delivery trends page as the counterweight.

Readiness

Why each item isn't ready to pull. Click any chip to filter.

An item is ready when it has an estimate, isn't bigger than the max item size, and meets whatever else you switched on in Settings. Max item size defaults to half of one person's sprint, so it scales when you change metric or assumptions.

How capacity is worked out

available days = working days − leave − holidays
capacity       = available days × allocation × hours per day × focus factor ÷ hours per unit

Focus factor is the share of the day really available for sprint work, after standups, reviews and interruptions. Default 80%. If your team consistently finishes 60% of what it commits to, this is the first number to lower.

Hours per unit converts an hours budget into your metric. One story point defaults to 4 hours. If your capacity numbers feel systematically wrong, this is the second number to change.

Two rules the maths follows that people often get wrong:

• A day lost to a public holiday isn't charged again as leave. Booking leave across a bank holiday doesn't cost you two days.
• Overlapping leave counts once. Two bookings on the same day cost one day, and a full day beats a half day.

Leave from Jira issues

The recommended setup, and it takes one dropdown. Go to Team → Where leave comes from, choose Jira issues, and pick your leave project from the list — projects that look like they hold leave are sorted to the top, and if there's an obvious one it's already selected. Press Test it to see what the app found before you save.

You never have to write a Jira query. If you want to — because the project holds more than leave — open Advanced and edit it directly. The app leaves a hand-edited query alone.

The app reads issues and never writes to them.

That last row matters: a leave request nobody has approved will not shrink your sprint. If your workflow doesn't have an approval step, tick Count leave in any status.

Export leave above the table downloads exactly the rows on screen as CSV.

Test it shows what was found and what was skipped, with the reason. If someone's leave isn't showing up, that button tells you why — usually a missing start date or a status that isn't approved yet.

Troubleshooting

Where your data lives

Nothing is stored by the app vendor. There's no external database and no data leaves your Jira.

• Leave, when read from issues, stays as Jira issues. The app only reads.
• Team roster, leave-source settings, and any hand-typed leave go in a Jira project property on your project: capacity-tracker.team. You can read it yourself:

`` GET /rest/api/3/project/{KEY}/properties/capacity-tracker.team ``

It survives uninstalling the app.

• Display preferences (metric mode, chart settings) sit in Forge storage, on Atlassian's infrastructure.
• Your light/dark choice is in your own browser only.