01
Velocity Stability
When invisible work absorbs capacity, the gap between what a team plans and what they deliver becomes erratic.
Consistency
55 %
§01 — Method
Starting from the data teams already keep.
Every software team does work that never shows up in Jira: mentoring juniors, responding to incidents, fixing things before they become tickets, answering questions in Slack. This invisible work drains capacity, skews estimates, and burns people out. The question IWRI was built to answer is narrow and specific: can you see the footprint of that work in the data teams already have?
The research behind IWRI was conducted across hundreds of Scrum teams in banking, telecommunications, and other sectors. Each participating team rated its own volume of invisible work through a structured survey. Team leads were then interviewed to map, in their own words, how that work manifested: the interrupt-driven weeks, the work absorbed before it reached the backlog, the tickets that never quite captured what the team had actually done.
From there, over twenty candidate indicators were tested against the self-reported burden. Some tracked sprint-delivery patterns. Some tracked ticket hygiene. Some tracked day-to-day activity rhythms. Any indicator that did not show a consistent, repeatable relationship with self-reported invisible work was removed. What survived is the set of seven.
§02 — From candidates to kept
Only patterns that held up twice.
Stage one
20+
candidate indicators across sprint delivery, tracking behaviour, and activity rhythms
Stage two
Hundreds
of Scrum teams across banking, telecommunications, and other sectors
Stage three
07.
validated indicators, each with a documented split-half reliability score between 53 and 86 percent
Indicators that did not show a consistent, repeatable pattern were discarded.
§03 — The seven that held up
Each captures a different face of invisible work.
Reliability below is measured as split-half consistency: how stable each signal remains when two independent halves of the underlying data are compared. A higher figure means the pattern is less likely to be the product of a single noisy sprint, and more likely to reflect something persistent about the team.
02
Commitment Gaps
Teams carrying invisible work consistently deliver less than they commit to, because their real workload is larger than what is tracked.
Consistency
74 %
03
Work Left Undone
Planned tickets that are never even started suggest untracked work displaced the planned work during the sprint.
Consistency
69 %
04
Tracking per Person
Teams tracking fewer items per developer than peers may have significant work happening outside Jira entirely.
Consistency
78 %
05
Daily Jira Activity
Frequent days with zero Jira activity can indicate the team is busy, just not with anything that shows up in the tool.
Consistency
81 %
06
Ticket Descriptions
Empty ticket descriptions often signal rushed ticket creation or work that was communicated verbally and never documented.
Consistency
86 %
07
Mid-Sprint Changes
Unpredictable volumes of unplanned work added mid-sprint suggest recurring interruptions from sources not captured in planning.
Consistency
53 %
§04 — Principles
Three constraints we accept on purpose.
01
Screening, not scorecard.
Flags indicate patterns worth investigating. They do not confirm a problem is present, and they are not a substitute for judgement.
02
Relative, not absolute.
Scores are meaningful within your scored population. Cross-organisation comparison is not supported, by design.
03
Conversation starter, not verdict.
The app points you at where to start a conversation with a team. What happens next is professional judgement, not algorithm.
Every formula, every threshold, and every known limitation of IWRI is documented inside the app itself, in plain language, with no statistical jargon outside of the Methodology tab. The app is read-only. No data leaves your Jira Cloud tenancy. Australian English throughout.