IWRI Eligibility Criteria
Last updated: 7 May 2026
The Invisible Work Risk Index (IWRI) is a screening tool that compares Scrum teams within your Jira instance against each other. To produce statistically meaningful comparisons, IWRI requires a minimum population of eligible projects, and each project must meet a small set of data-quality criteria. This page describes both.
Population minimum
IWRI requires at least 20 eligible Scrum projects on a single Jira Cloud site. Below this threshold, the app will install but cannot produce risk scores: there is not enough comparable data to compute a stable population mean and standard deviation, which IWRI uses to standardise every indicator. If your site has fewer than 20 eligible projects, IWRI will display an explanation in the Settings tab rather than misleading numbers.
Why 20? The risk levels IWRI surfaces are relative, not absolute. Every indicator is converted to a z-score showing how far a team sits from the population average. With too few teams in the population, individual outliers swamp the average and make the standard deviation unstable, so flags would fire or fail to fire essentially at random. Twenty is the smallest population at which the population statistics begin to behave reliably.
Per-project eligibility criteria
Each Scrum project on your site is evaluated against eight criteria. A project is eligible only if it passes all eight. Projects that fail one or more are excluded from the scored population. They still appear in filter dropdowns (greyed out, marked “Excluded”) so admins can see them, but they do not contribute to or receive scores.
| Criterion | Threshold | Why it matters |
|---|---|---|
| Project maturity | At least 90 days old | New projects lack the historical data needed for reliable trend analysis. Scoring them too early would produce misleading comparisons. |
| Recent activity | Activity within the last 30 days | Dormant or archived projects would skew the population statistics with stale data, distorting z-scores for active teams. |
| Workflow configuration | In Progress and Done status categories | IWRI relies on workflow transitions to measure work patterns. Without these categories, key indicators like velocity and commitment cannot be computed. |
| Sprint history | At least 2 completed sprints in the last 90 days | A single sprint provides no basis for comparison or trend detection. At least two data points are needed to identify patterns. |
| Team size | At least 3 distinct assignees | Very small teams (one or two people) produce statistically unreliable per-person metrics and can generate misleading outlier scores. |
| Sprint duration | At least 1 sprint of 7 or more days | Very short sprints (for example one-day spikes or test sprints) do not represent normal work cadences and would distort velocity-based indicators. |
| Board type | Scrum board | IWRI’s methodology rests on sprint-scoped commitment, completion, and mid-sprint-change signals. None of these have meaningful equivalents in Kanban, so Kanban-only projects are not analysed. |
| Data availability | Project data loadable from Jira | When a Jira lookup fails (project deleted, permission lost, network error), IWRI cannot judge maturity or activity reliably. The project is surfaced so admins can investigate, and returns to eligibility automatically once the data loads on the next run. |
Administrator exclusions
Administrators can also explicitly exclude a project that would otherwise pass the criteria, for example a sandbox project, a training board, or a team undergoing a major restructure. Excluded projects appear with an “Admin excluded” label in the Settings tab and do not contribute to scoring.
What exclusion means in practice
Excluded projects are not part of the scored population and do not influence the z-score distribution. They still appear in filter dropdowns, greyed out and marked “Excluded”, so you can see which teams belong to each group, but they cannot be selected for reports. If a team’s circumstances change (for example it gains more sprint history, or completes its first 90 days), it automatically becomes eligible in the next computation run.
Pre-installation check
Before installing, you can estimate whether your site is likely to meet the threshold by counting Jira projects that:
- Are at least 90 days old
- Are backed by a Scrum board
- Have completed two or more sprints in the last 90 days
- Have at least three distinct assignees
If you have at least 20 such projects, IWRI will produce reliable scores. After installation, the Settings tab shows a live eligibility assessment with per-project verdicts, so you can see exactly which projects are eligible, excluded, or close to passing.
Methodology
For the full methodology, including the seven indicators, the z-score standardisation, and the five flags, see the IWRI Methodology page.