Capasight:Lite resources

How the app measures demand, what each finding means, and what it needs from your Jira data. The app itself carries a setup guide for the steps; this page is the model behind the numbers.

How it works

Every finding in Capasight has the same shape: something a person stated, against what the underlying work actually says. Jira holds both halves and compares neither.

Two estimates, and the larger one wins

An item carries a t-shirt size that somebody stated early, and a sum of estimates written later by the people doing the work beneath it. The larger of the two is the dominant estimate. A t-shirt acts as a floor until the breakdown beneath it overtakes it, which is what stops work nobody has elaborated yet from reading as zero demand.

This is the same at every level. An initiative's t-shirt is measured against the features beneath it; a feature's against its epics; an epic's against its stories. The app never assumes the size above and the work below agree — comparing them is the point.

Capacity is consumed over a window, not on a date

An item running January to April consumes capacity in every sprint between. Loading its whole size into April would invent a spike there and show the sprints actually doing the work as empty, so demand is spread across the sprints an item's window covers. That is why a start date matters as much as a due date: without a beginning there is no window, and the app reports the item rather than guessing one.

Demand is what is left to do

A forecast is about the sprints ahead. Work already delivered consumes no future capacity, so demand is the dominant estimate less whatever has been accepted — never the whole size of a half-finished epic.

Stated: t-shirt M — 20 points
Elaborated: three stories: 13, 8 and 21 — 42 points
Accepted: the 13 and the 8 are done — 21 points
Dominant estimate: 42, because the breakdown has overtaken the t-shirt
Remaining pts.: 21 — the 42, less the 21 already accepted
Elaboration: 210% — the stories are twice the stated size
Completion: 50% — 21 accepted against the whole epic

Re-sizing that epic would change nothing. The plan already counts all 42 points, because demand takes the larger of the two estimates. What is worth knowing is whether the teams can absorb the extra — so the app raises a finding only where that work lands in a sprint that is already over capacity.

Levels and the hierarchy

Jira lets a site define its own work-type hierarchy above the epic. Capasight reads whatever yours actually is rather than assuming three levels or assuming what they are called — a site with Initiative, Feature and Epic is described that way; a site with something between them is described that way instead.

The same question at every adjacent pair

Every level is analysed in its own right. Switch the level on any screen and the tables, the findings and the capacity forecast are all rebuilt for it: features against the initiatives above them, epics against the features, stories against the epics. A finding at one level does not imply one at another, and each is worth knowing separately.

Each level has its own size scale

An XL initiative and an XL feature are not the same amount of work, so each level carries its own mapping from t-shirt size to points. A level left unconfigured is treated as a connecting level: its children still roll up through it, but it is not measured against a scale it never had.

Where the sizes came from

The t-shirt size is read from whichever custom field you map, at every level. The evidence half is read from the work below: story points where they exist, and the dominant estimate rolled up from the level beneath where they do not yet. That is what lets a portfolio be measured months before anybody has written a story.

Your portfolio is read once, not on every page

A large portfolio — several thousand epics and everything above them — cannot be read inside the time a page load allows. So it is read once in the background and every screen is served from the result, which is why the app opens as quickly on a large portfolio as a small one. The header shows when the data was read, and Refresh reads it again whenever you want. It also refreshes itself if the data is more than twelve hours old, or when an administrator changes which projects are in scope.

Teams, ARTs and value streams

This is the part of the model that exists because Jira has no equivalent. Jira records work against one team at a time and offers no grouping above it, so the question a PI planning session actually asks — what has this ART committed to, collectively? — has no answer in Jira.

Three tiers, from the teams you already have

Teams come from Jira's own Team field: the names really on your issues, not free text. In configuration you say which of those teams represents an ART, and which ARTs belong to which value stream. Nothing is created or changed in your Jira — the grouping lives only in Capasight, and removing it changes nothing in your site.

Work reaches a group two ways, and both count

Route	What it means
Stated	The item carries the ART's own team in its Team field, so Jira already says which group owns it. This is common for initiatives and features early in planning, before anything has been assigned to a delivery team.
Inherited	The item carries a delivery team, and that team belongs to the ART. The work reaches the group through membership.

Naming a team as an ART therefore adds to that ART's scope rather than narrowing it: a group owns both the work assigned to it directly and the work its teams are doing. Anything else would hide half the plan.

The split between them is itself a signal

Early in a PI most of a group's demand sits at ART level, waiting to be broken down; as planning proceeds it moves to teams. Capasight reports that ratio, which answers “how far through breakdown is this ART” without anyone counting. A group still holding three quarters of its demand a fortnight before the PI starts is worth a conversation.

Capacity, in points or in team-days

A group's capacity is the velocity of the teams in it. Velocity is either stated per team in configuration, or derived from what that team's recent sprints actually delivered — and where both exist, the app shows the drift between them, because a team planning at half again what it delivers is the reason a plan fails.

Every figure can be read in points or in team-days. Team-days are derived at each ART's own rate — velocity divided by teams and days per sprint — rather than at one global constant, so the conversion reflects that group's real throughput.

Glossary

The same words are used on every screen. Where the app shows a figure, this is what it means.

Term	What it means
Estimate	The two figures side by side — the t-shirt size somebody stated, and the story points written beneath it. The dominant one is shown in bold, because every other number on the row derives from it.
Remaining pts.	What an item has left to do: the dominant estimate less the work already accepted. This is the figure the capacity chart places.
Over cap. pts.	How much of that demand lands in a sprint that is over capacity. Involvement rather than blame — a sprint is over because of everything in it, so two items contributing equally are equally involved.
Elaboration	How much of the stated size has been broken down into estimated children. It is not capped: past 100% the breakdown has outgrown the t-shirt. Green inside your variance tolerance, amber past it, red at double the stated size.
Completion	Accepted work as a share of the whole item, not of the part somebody has written stories for. An epic sized XL with 34 points elaborated and 21 accepted is 21% complete, not 62%.
Scope drift was: size drift	The story points beneath an item have outgrown the size it was given, by more than the site's variance tolerance.
Deadline passed was: lapsed	The due date has gone and work is still open. The remaining points are carried into the current sprint — it is already late, so no future date can honestly be inferred for it.
Deadline at risk	The due date is still ahead, but the child work already runs past it. The most actionable finding in the app, because it fires before anything in Jira would flag it.
No end date was: inferred	Work is under way with no end date anywhere — not on the item, not on the work beneath it. All of its demand loads into the current sprint, because that is the only thing the data supports.
No window was: unplannable	No start date and no work under way, so there is no window to spread the demand across. A due date on its own says when the work must end, not which sprints it consumes. These items are excluded from every forecast and reported instead.
ART	A grouping of Jira teams, defined in the app's configuration. Jira has no level above the team, so this exists only in Capasight — nothing is created or changed in your Jira. One of the teams may be named as the ART's own, so work stated against it counts alongside the work its teams are doing.
Value stream	A grouping of ARTs, and the tier above them. Value streams group ARTs rather than teams directly, so a team belongs to a value stream through its ART. Filter by one to see everything its ARTs have taken on, then narrow to a single ART from there.
Level	One tier of your Jira work-type hierarchy — Initiative, Feature, Epic, or whatever yours are called. Every screen can be read at any level your site defines, and each level carries its own size scale and its own capacity forecast.
Stated / inherited	How work reached a group. Stated: the item carries that group's own team in its Team field. Inherited: it carries a delivery team belonging to the group. Both count toward what the group owns, and the split between them says how far through breakdown the group is.
Velocity drift	The gap between the velocity a team planned with and what its recent sprints actually delivered. A team consistently planning above what it delivers is why a plan that looked achievable was not.
Team-days	The same demand read in days rather than points, derived at each ART's own rate — its velocity divided by its teams and its days per sprint — rather than at one rate for the whole site.

What each finding is telling you

Finding	What to do about it
Deadline passed	Re-plan to a realistic date, or split what remains into a new item. Until then the work sits in no plan while still consuming the current sprint.
Deadline at risk	Move the date out, or pull the child work into earlier sprints. The date has not lapsed yet, so nothing else has flagged it.
Scope drift	Move some of the work to a later sprint, or accept the overrun deliberately. Re-sizing the item changes no figure — the forecast is already using the story points rather than the t-shirt.
No end date	Set a due date, or put target dates on the child work. Either gives the window an end and spreads the demand across the sprints it will really take.
No window	Set a start date, or start the work — either one gives the item a beginning. Where no dates exist at all, set both or close it if the work is not real.

What the app needs from Jira

Findings degrade gracefully: each one names the field it depends on and says so when it cannot run, rather than reporting a zero that looks like good news.

Field	What it unlocks
Story points	The evidence half of every size finding. Company-managed projects use Story Points and team-managed use Story Point Estimate — the app reads whichever is populated.
T-shirt size	The stated half. Any single-select field will do; the scale and what each size is worth are set in the app.
Start date	Gives an item a window. Without one it reaches no forecast and is reported under No window.
Due date	Ends the window, and drives every date finding.
Team	Only needed for ART capacity and cross-team views. Everything else works without it.

A field can exist site-wide and still read as empty. If it is not on the screens a project uses for that issue type, the app sees nothing — which looks identical to the field simply not being filled in. The app's Configuration tab reports which fields it matched and how much of your data actually carries them.

Security and privacy

Nothing leaves your site. The app makes no external calls and uses no third-party services, so there are no subprocessors. All compute and storage is Atlassian's, and the app is eligible for Atlassian's Runs on Atlassian programme.
Read-only. Four scopes, all read, and no Jira write scope at all. The app cannot change your issues, and the issue panel is display-only by design rather than by omission.
Your permissions apply. You only ever see work from projects you can already open in Jira — two people on the same screen see two different portfolios if that is what their permissions say. Configuration is site-wide and can only be changed by a Jira administrator, checked on the server rather than by hiding a button.
What is stored. Configuration — team, ART and value stream names, velocities, project keys, field ids, cadence and the size scales — and a snapshot of your portfolio, so the screens do not have to re-read Jira every time somebody opens them. The snapshot holds work-item fields: keys, summaries, dates, sizes, rolled points, status and team name. No descriptions, no comments, no attachments, and no assignee, reporter or other user identity. Atlassian holds both inside your own site, pins them to your data residency region, and deletes them when the app is uninstalled.
No API tokens. The app never asks for, transmits or stores an Atlassian API token.

Support

Email contact@capasight.co.uk. Telling us the app version from the Configuration tab and what the screen said gets to an answer fastest.

The app carries its own setup guide covering field mapping, the size scale, thresholds, teams and ARTs, and the sprint cadence — including what to check when a figure reads zero.