Everything IWRI does, how it does it, and how to run it well.

§ 01 Overview

The Invisible Work Risk Index (IWRI) is an Atlassian Forge app for Jira Software Cloud. It reads sprint and issue data you already keep in Jira, computes seven behavioural indicators for each eligible Scrum team, and places every team at one of six risk levels on the basis of how much evidence their data shows of invisible work — effort occurring outside normal sprint tracking.

“Invisible work” is a broad term for the work that drains capacity without reaching a ticket. The friendly kind: mentoring juniors, triaging incidents, fixing things before they become reportable problems, answering questions in Slack. The harder kind: requests that arrive verbally, handovers that stay verbal, tickets written after the fact. Teams carrying a lot of invisible work tend to leave specific signatures in their Jira data. IWRI scores those signatures.

Who IWRI is for

• Delivery leads and engineering managers who want to scan a portfolio of Scrum teams and see where attention is worth spending.
• Agile coaches and ways-of-working practitioners who want evidence-backed conversation starters for their coaching cadence.
• Jira site admins and delegated app admins who configure scope, schedule, access, and administrators.

What IWRI deliberately does not do

• Does not write to Jira. The app declares read-only scopes plus storage:app.
• Does not track time, log hours, or score individuals. All indicators are team-level.
• Does not send data outside your Jira Cloud tenancy. The manifest declares no external fetch domains; the Forge sandbox enforces that at runtime.
• Does not support Kanban projects in v1. They are surfaced as excluded with the reason “Kanban (not supported)”.
• Does not expose statistical jargon (z-scores, sigma, alpha) in Dashboard, Reports, Settings, or Onboarding. Those terms appear only inside the Methodology tab.
• Does not produce scores when fewer than 20 eligible Scrum teams are available; the run fails with a population-minimum message instead of producing statistically unreliable numbers.

§ 02 Install & set-up

IWRI is installed from the Atlassian Marketplace like any other Forge app. A Jira site administrator approves the requested scopes at install time, which is the only moment the app requests user action from the site administrator.

Prerequisites

• An Atlassian Jira Cloud site with at least some Scrum-configured projects.
• A user with the Jira ADMINISTER global permission to perform the install.
• To produce scores on the first run, at least 20 eligible Scrum teams must be present in the instance (see § 13 Known limitations).

Scopes requested

No write:* scopes are requested. No manage:* scopes are requested.

Post-install state

Installing the app loads it with safe defaults (access mode Open, cadence Daily, no excluded projects, no team groups, the installing admin becomes the sole IWRI admin). The first administrator to open IWRI is greeted by the onboarding dialog (see § 03). On Finish setup or Do this later, IWRI automatically runs the first computation in the background and reloads the Dashboard with results when it completes — no Settings round-trip is required to see scores. Admins can still trigger a recomputation on demand at any time from Settings → Recompute.

§ 03 First-run onboarding

The first administrator to open IWRI after install is greeted by a guided six-step onboarding dialog. The state is stored per Jira site (not per admin), so if one admin pauses at step 4, the next admin to open the app resumes at step 4.

The six steps

1. Welcome. Orients the admin to what IWRI is and what the tour will cover.
2. Groups. Optional. Admins can create named team groups that group projects for reporting purposes (e.g. “Payments stream”, “Platform teams”).
3. Access. Choose one of three access modes: Open, Project-scoped, Admin-granted. See § 10 Access control.
4. Administrators. Delegate app-admin rights to non-Jira-admins (optional).
5. Schedule. Choose recompute cadence: Daily or Weekly.
6. Notes. Introduction to team annotations — free-text notes admins can attach to any team, visible to anyone with access to that team's scores.

Any step can be skipped. The entire flow can be skipped with “Do this later”, which records an onboarding:state of skipped. Admins can resume onboarding from a banner that appears at the top of the Settings tab whenever the state is not completed.

Automatic first computation

Once the admin clicks Finish setup on the final step (or chooses Do this later to skip), IWRI takes over the first computation automatically. A full-screen overlay confirms that the first analysis is being prepared, the indicator pipeline runs in the background, and the dashboard reloads with results when the run completes — typically within a few minutes. No additional click is required to see scores after onboarding. If the run fails, the overlay surfaces the error with a Try again action so the admin can retry without leaving the page.

§ 04 Core concepts

Four ideas underpin every IWRI screen:

1. Invisible work

Work that drains team capacity but does not show up as a Jira issue, or does not show up at the time the work actually happens. Mentoring, incident triage, informal support, verbal handovers, ticket-after-the-fact documentation. It is a real dimension of engineering work; it is simply under-tracked.

2. Behavioural signatures

Teams carrying significant invisible work tend to leave specific, measurable patterns in their Jira data. IWRI computes seven of these patterns ("indicators") from the last eight completed sprints within a 90-day window for every eligible Scrum team. Each indicator is a single numerical value with a specific formula.

3. Relative standardisation

Raw indicator values are measured in different units (coefficients of variation, ratios, proportions) and are not directly comparable. Each raw value is z-score standardised against the scored population for your Jira instance. A z-score of 1 means “one standard deviation above the population mean, in the direction of higher risk”. Standardisation is always relative to your teams, never an industry benchmark.

4. Risk levels

Each team receives exactly one of six risk levels, derived from how many of five flags fire for that team:

§ 05 Dashboard

The Dashboard is the primary view. It shows every eligible Scrum team in your site as a card, colour-banded by risk level, alongside a hero summary that states the population-level position in one sentence.

Intro bar and freshness

The intro bar, present on every tab, shows the app icon, the introductory paragraph, and a freshness badge stating when the current scores were computed. If a run is currently in flight, a “Recomputing” pill appears; it is visible to every user, not only admins.

Hero summary

The hero summary is a one-sentence statement at the top of the dashboard. The exact wording adapts to the population:

• If every team is Healthy: “All teams are healthy. No elevated invisible work risk detected.”
• If one or more teams are at Elevated or High risk: “N of M teams show elevated invisible work risk.”
• Otherwise: “N of M teams show signs of invisible work.”

Team card grid

Each card displays the project code, the project name, the current risk level, and the number of flags firing out of the five applicable. A coloured band at the top of the card encodes risk level for fast scanning. Clicking a card opens the drill-down view.

Team-group sections

When team groups are configured (Settings → Groups), the dashboard renders eligible teams under their group name as a heading, with one card grid per group. Groups appear in the order they are declared in Settings; any group whose teams have all been filtered out collapses silently. Teams that do not belong to any configured group fall into a trailing “Ungrouped” section. With no groups configured, the dashboard remains a single flat grid. Within a group, the existing sort applies: bookmarked teams first, then by risk level, flag count, and project name.

Bookmarks

Any user with access can bookmark a team. Bookmarked teams are pinned to the top of the grid on their next visit. Bookmarks are stored per user, per site.

Not included in analysis

Teams that were considered but did not meet all of the eligibility criteria are listed in a collapsible “Not included in analysis” section below the main grid (admin-visible by default; see § 10). The same teams appear as the Excluded Teams report on the Reports tab. Each team shows the criterion or criteria it failed:

• Kanban (not supported) — board is Kanban, not Scrum.
• Not enough history — project is less than 90 days old.
• Inactive in recent sprints — no issue updates in the last 30 days.
• Incompatible workflow — workflow is missing the In Progress or Done status categories.
• Too few completed sprints — fewer than two completed sprints in the 90-day window.
• Sprints too short — no completed sprint of seven days or longer.
• Too few team members — fewer than three distinct assignees on Story, Task, or Bug issues across the analysed sprints.
• Admin excluded — manually excluded via Settings → Excluded Projects, regardless of whether the team would otherwise have qualified.

Excluded teams are not part of the scored population and do not influence any other team’s z-scores. If a team’s circumstances change (it accrues more sprint history, gains more assignees, becomes active again), it automatically becomes eligible on the next computation run.

§ 06 Team drill-down

Clicking a team card opens the drill-down view, replacing the card grid in place. A Back button returns to the grid. The drill-down is where managers and coaches do the real work: read the flags, inspect the indicator evidence, decide whether a conversation is warranted.

What you see

• Team header with the project code, name, current risk level, and the number of sprints analysed.
• Flag cards for every flag that fired, each with a plain-language explanation of what the signature means and what it might suggest.
• Indicator evidence: for every indicator, the raw value, the z-score against the population, and a small sparkline-style visual where applicable.
• Sprint-level evidence: a drill into which sprints triggered which indicators, where the data exists.
• Annotations panel: free-text notes authored by admins, visible to anyone with access to the team. Notes can carry an optional expiry date.
• Board override (admin-only): a dropdown to manually select which Scrum board represents the team's planning, if IWRI's automatic selection is wrong.

Plain language by design

The flag cards deliberately avoid statistical terms. Z-scores and sigma notation appear only in the Methodology tab. The flag copy is written to start a conversation, not to render a verdict: “This team tracks fewer items per developer than peers, which may indicate work happening outside Jira”, not “z(ticketDensity) = -1.3, flag fires”.

Board override

Jira projects can have multiple boards. IWRI auto-selects the most active Scrum board. If that selection is incorrect, an admin can override it via the drill-down. Saving a board override triggers an immediate recompute for the affected team; progress is shown live in the drill-down with a spinner and stage indicator.

Annotations

Annotations let admins record context that persists across recomputes: “Team just absorbed the Billing pod — expect volatility for two sprints”, “On-call rotation started 15 April”, etc. Non-admins can read annotations but not edit them. Annotations can have an optional expiry date, after which they stop being displayed (but are preserved in storage).

§ 07 Reports

The Reports tab shifts the focus from individual teams to the scored population as a whole. It is the primary view for agile coaches and ways-of-working practitioners who want to understand org-wide dynamics, not just outliers.

Five sub-reports are available:

Risk Overview

A distribution chart showing how many teams fall into each of the six risk levels. Useful for tracking movement over time (“last quarter we had 3 High, this quarter we have 1”).

Flag Patterns

Flag co-occurrence analysis: which pairs of flags tend to fire together? Where certain flag combinations are especially common in your population, the report surfaces them with a plain- language interpretation (for example, combined Tracking per Person and Commitment Gaps may indicate significant invisible workload in ticketing-averse teams).

Compare Teams

Side-by-side comparison of up to four selected teams. Useful for before/after analyses or for comparing teams within a group.

Excluded Teams

A reference view listing every team that was considered but not scored, with the exact exclusion reason. Helps admins understand why a team they expected to see is missing.

Distributions

Raw-value distributions of each of the seven indicators across the scored population, with partial-data coverage noted. This is the report that most directly surfaces data quality issues in your Jira instance (e.g. a long tail of empty-description tickets).

§ 08 Methodology in depth

The in-app Methodology tab is the authoritative reference. This section mirrors its structure and can be read in parallel.

Data window

• Sprints analysed: the last eight completed sprints within a 90-day window, per project.
• Minimum sprint duration: seven days. Sprints under seven days are excluded.
• Issue types: Story, Task, Bug. Sub-tasks and Epics are excluded.
• Commitment window: an issue is “committed” to a sprint if it was added within two calendar days of sprint start. Issues added later are mid-sprint additions.
• Team size floor: three or more distinct assignees across the analysed sprints.
• Population floor: 20 eligible Scrum teams in the site, or the run fails.

Eligibility rules (exhaustive)

1. Project board is Scrum (Kanban excluded as unsupported in v1).
2. Project is at least 90 days old, measured from the creation date of its oldest issue (maturity gate).
3. At least one issue has been updated within the last 30 days (activity gate).
4. Project workflow includes both an “In Progress” and a “Done” status category.
5. At least two completed sprints within the 90-day window, with at least one sprint of duration ≥ 7 days.
6. At least three distinct assignees on Story, Task, or Bug issues across the analysed sprints.
7. Project not manually excluded by an admin (Settings → Excluded Projects).
8. Project fits the global population cap (details surface in the Methodology tab).

A team that fails any rule above is routed to the “Not included in analysis” section on the Dashboard (also surfaced as the Excluded Teams report on the Reports tab) with the exact failed criterion shown. Excluded teams do not enter the scored population and do not affect any other team’s z-scores. The maturity and activity gates are computed against live Jira timestamps on every run, so a project becomes eligible automatically the moment it qualifies.

The seven indicators

Three feed the composite signal Completing Less Than Planned:

Velocity Stability

Measures how inconsistent a team's completed work is relative to total demand.

Commitment Gaps

Average shortfall between commitments and deliveries. Over-delivery is clamped to zero.

Work Left Undone

The proportion of committed work that was never started by sprint close.

Four are independent signals, each driving its own flag:

Tracking per Person (sign-flipped)

Issues tracked per person per sprint-week. Lower value means higher risk; the z-score is multiplied by −1 so that positive z always means higher risk.

Daily Jira Activity

The proportion of working days with zero Jira activity.

Ticket Descriptions

The proportion of completed tickets with empty descriptions.

Mid-Sprint Changes

The volatility of mid-sprint additions across sprints.

Z-score standardisation

Every raw value is standardised against the population mean and standard deviation.

Standardisation is relative to your population. Cross-organisation comparison is not supported — a team that is z = 1.5 in one organisation might be z = 0 in another.

The five flags

The flag threshold is strict inequality, z > 1. A z-score of exactly 1.0 does not fire a flag. The strictness is deliberate; converging flags each past a non-trivial threshold are a stronger signal than any one alone.

Null propagation

Data gaps are never papered over. If a raw indicator cannot be computed (e.g. a team had zero sprints with committed items), the raw value is null. The resulting z-score is null. Nulls are never replaced with zero or a default. If all seven z-scores are null, the team's state is Insufficient data, not Healthy.

Reliability

Each indicator has a documented split-half reliability score (the consistency of the pattern when two independent halves of the underlying data are compared). The seven signatures in v1 range from 53 % (Mid-Sprint Changes) to 86 % (Ticket Descriptions). Reliability values are visible in the Methodology tab inside the app.

Research provenance

The seven indicators emerged from studying hundreds of Scrum teams across banking, telecommunications, and other sectors. Teams self-reported their invisible-work burden through structured surveys; team leads were interviewed to map how invisible work manifested. Over twenty candidate indicators were tested; only the seven that showed consistent, repeatable correlations with reported invisible work were kept. Full provenance at research.html.

§ 09 Settings & administration

The Settings tab is admin-only. It is not rendered in the tab list for non-admins; any deep-link attempt is silently discarded. Seven sub-sections are available:

Recompute

Trigger a recomputation on demand. The UI shows a spinner and live stage indicator while the job runs (fetching data, computing indicators, standardising, applying flags, persisting). When the run finishes, the page reloads automatically so the new scores appear without further interaction. Admins also have a Clear history option for wedged states that deletes all historical run records while preserving the last successful score set.

Schedule

Choose a cadence of Daily or Weekly. Saving a cadence change auto-triggers a recompute (no-op saves skip the trigger). When that recompute finishes, the page reloads automatically; live feedback while it runs mirrors the Recompute section.

Excluded Projects

Manually exclude projects from analysis. The picker is group-aware: projects are grouped by team group where applicable, with per-group Select all toggles. Projects that fail eligibility criteria are still selectable but display an EXCLUDED lozenge. Saving exclusion changes auto-triggers a recompute and reloads the page when results are ready, so the Dashboard always reflects the latest population.

Groups

Create named groups of projects (e.g. “Payments stream”). Groups are available for organisation-wide reporting and for scoping admin-granted access rules. Each group is a list of project keys.

Administrators

Delegate app-admin rights to specific users who are not Jira site admins. An app-admin has full administrative capability within IWRI but no Jira site-admin privileges outside the app. Jira site admins are always implicit IWRI admins.

Access

Choose the access mode for the site. See § 10 Access control for the three modes and their rule schemas.

Team Notes

Review, edit, or delete annotations across all teams in one place. This is the bulk editor for the annotations that appear in team drill-downs.

§ 10 Access control

Every access decision runs through a single getAccessStatus resolver on app mount. The resolver returns canAccess (boolean) and isAdmin (boolean). If canAccess is false, the app renders the Access Restricted screen and loads no further data.

Access modes

Capability matrix

All admin gates are enforced server-side in the resolvers, not only client-side. UI hiding is defence-in-depth; a non-admin attempting to invoke a write resolver directly receives a structured error envelope without side effect.

§ 11 Privacy & security

IWRI is a Forge app. All code runs inside the Atlassian Forge sandbox, on Atlassian's infrastructure, within your Atlassian Cloud tenancy. The developer has no direct access to your site, credentials, tokens, or Jira data at any point, including during support.

Data the app accesses

Read-only Jira data as specified by the declared scopes: projects, issues, changelog, boards, sprints, and user display names. All reads are initiated from within the Forge sandbox. The app makes zero external fetch calls; the manifest declares no permissions.external.fetch.backend entries, and the Forge runtime silently blocks any undeclared egress.

Data the app stores

Only derived aggregates and admin configuration, in Atlassian Forge Key-Value Storage (@forge/kvs), scoped to your installation:

• Per-project risk scores and category flags (numerical values, short enum labels).
• Admin configuration: access mode rules, recompute cadence, excluded projects, team groups, app-admin list.
• Team annotations (short free-text notes authored by admins, with optional expiry).
• Run metadata: timestamps, run IDs, stage names, error categories.

The app does not store: issue summaries, descriptions, comments, attachments, user PII, sprint names, or issue keys beyond what is needed to label aggregate outputs.

Data residency

Follows Atlassian Forge platform residency. The developer operates no external infrastructure; customer data physically resides wherever your Atlassian Cloud tenancy is provisioned.

Uninstall

Atlassian Forge purges all app-managed storage when the app is uninstalled. The developer takes no additional action; the platform enforces the purge.

Subprocessor

A single subprocessor: Atlassian Pty Ltd, the platform host. No other parties.

Full details at privacy.html.

§ 12 Pricing & licensing

IWRI is billed through the Atlassian Marketplace. Atlassian handles all payment, taxation, and invoicing on the developer's behalf. The developer never receives your payment information.

Tier ladder

Annual is equivalent to approximately ten months per year (~17% discount). A thirty-day free trial is included on every paid tier by the Atlassian Marketplace.

Trial or subscription lapse

When a trial ends or a subscription lapses without renewal, the app's paid surfaces (Dashboard, Reports, Settings, Methodology) return a “Licence inactive” state with a “Manage subscription” call-to-action that deep-links to the Jira Apps admin page. Onboarding and access-status endpoints remain responsive so an administrator can renew. No data is deleted during a lapse; re-activating the licence restores full access immediately.

§ 13 Known limitations

• Scrum only in v1. Kanban projects are explicitly excluded with reason Kanban (not supported). Extending to Kanban would require a separate indicator set; v1's seven signatures are calibrated against Scrum practice.
• Population minimum of 20 teams. Below that, population-relative scoring is statistically fragile. The run fails with a clear message rather than produce unreliable numbers.
• Relative, not absolute. Scores are meaningful within your site. Cross- organisation comparison is not supported.
• Adapted teams may be missed. Teams that have already accommodated invisible work (e.g. inflated estimates) may not trigger flags because their patterns look “normal” against the population.
• Persistence, not prediction. Reliability values demonstrate that patterns persist across sprint halves; they are not predictive or construct validity.
• Uniform sizing assumption. Issue-count-based indicators assume roughly uniform issue size. Highly variable story-point distributions may distort results.
• Team-size confound. Daily Jira Activity correlates inversely with team size (r ≈ -0.28). Smaller teams naturally have more zero-activity days. The confound is noted in the Methodology tab; it is not adjusted for.
• Desktop-primary UI. Viewports below 1024px do not adapt ideally in v1.

§ 14 FAQ & troubleshooting

I expected to see a team scored, but it isn’t on the Dashboard. Where is it?

A team that fails any eligibility rule is routed to the “Not included in analysis” section at the bottom of the Dashboard (and shown as the Excluded Teams report on the Reports tab) with the exact failed criterion. Common reasons: the project is Kanban; the project is less than 90 days old; no Jira issue has been updated in the last 30 days; the workflow lacks an In Progress or Done category; fewer than two completed sprints of ≥ 7 days; fewer than three distinct assignees on Story, Task, or Bug issues; or an admin has manually excluded the project via Settings → Excluded Projects.

What does the “Insufficient data” risk level mean?

The team passed every eligibility rule but the indicator pipeline could not produce a usable z-score on any of the seven signals — for example, a team with completed sprints but no committed items, or no completed items in the analysed window. The team is shown on the Dashboard with the Insufficient data lozenge rather than being placed at Healthy by default. Eligibility failures (sprint count, team size, maturity, activity, workflow, board type) are not shown as Insufficient data; those teams appear under Not included in analysis instead.

The run failed with a population-minimum error. What do I do?

IWRI refuses to produce scores on fewer than 20 eligible teams. Either wait for more teams to accrue sprint history, or reduce exclusions. If your organisation genuinely has fewer than 20 active Scrum teams, IWRI is not the right fit in v1.

Can I compare our scores to another organisation's?

No. Scores are relative to your own population. A team at z = 1.5 in one organisation may be at z = 0 in another. The app deliberately does not support cross-organisation comparison.

Are my team members able to see their individual scores?

There are no individual scores. All indicators are team-level aggregates. IWRI does not score, rank, or identify individual contributors. Nothing in the codebase ties an indicator value to a specific person.

Will installing IWRI change anything in our Jira data?

No. IWRI holds read-only scopes and performs no writes to Jira. Installing and uninstalling is non-destructive to your Jira content.

A computation is stuck. How do I recover?

Open Settings → Recompute and use the Clear history affordance. It deletes the historical run records that may be in a wedged state while preserving the last successful score set on the Dashboard.

Our licence expired mid-use. Did we lose any data?

No. Configuration, annotations, exclusions, and the most recent scores remain in Forge storage during a licence lapse. Re-activating the subscription restores access immediately; no data is re-computed or re-seeded by the reactivation.

Who can see annotations on a team?

Anyone with access to that team's scores under the current access mode. Annotations are visibility-coupled to scores. In project-scoped mode, only users with project-admin rights on that project see the annotations.

§ 15 Support

IWRI is developed and maintained by Ayman Idris (ABN 59 540 661 752), based in Sydney, Australia.

• Email: idrisayman88@gmail.com
• Response target: two business days, best-effort (solo developer).
• Hours: Australian business hours (AEDT / AEST).
• Critical issues: include “URGENT” in the subject line.

For methodology questions, the in-app Methodology tab is the authoritative reference. For privacy or compliance enquiries, see the Privacy Policy. For licensing questions, see the Terms of Service.