Skip to the reportSkip to report

As of 2026-08-13 · pulled 13 Aug 2026, 23:31 (same day as the last Jira change)

4 R1 user stories in Value Add.

SummaryJira

No thresholds declared

0% of R1 user stories have passed QA, 3 are in flight, and 0 have reached SIT or beyond.

  • “Delivered” means development complete and QA passed — not released. SIT, pre-production and release all come after it.
  • Every figure on this page counts user stories only, matching the workflow above. Delivery is executed on the technical tasks beneath a story, and those are not counted here — so this measures scope a business reader recognises, not effort spent.
  • No issue links are recorded for Value Add, so an empty dependency row means not recorded rather than not blocked.
R1 delivered

Development complete and QA passed. Not released.

R1 delivered

0%

0 of 4 R1 user stories

Completed in sprint 18

User stories whose completion date falls in sprint 18. The comparison is against sprint 17, which is complete, so part of the gap is time not yet elapsed.

Completed in sprint 18

0

Sprint 18 is still running

Carry-over

Sprint 17, the last completed sprint. In its final scope, not finished when it ended, and in a later sprint.

Carry-over

0 of 0 in sprint 17 scope

Commitment reliability

Completed on or before the due date.

Coverage. 0 of 0 completed items carry a due date

Commitment reliability

0 of 0 completed with a due date

Released to production

User stories with a recorded transition into the Production phase, at any point. Not stories sitting in it now — released work moves on to Complete, so the current count is zero and always will be. The programme figure beside it counts every issue type.

Released to production

0

No user story has entered production

Stories blocked

Unfinished user stories on the receiving end of a Blocks or Depends link. What holds them up is counted whatever its type.

Coverage. See dependency coverage by squad

Stories blocked

0

0 blocked by another squad · 0 from outside the four

9% past QA, 0 in production nowJira

324 R1 stories, and how they moved through the workflow
How to read the workflow, and what it does not say
Every status the Jira workflow configures, in the order work walks them, for user stories — the population every figure on this page reports. Task and Technical Task run a workflow with no test gates, and mixing them made 88% of the apparent skips artefacts of the mix. A CIRCLE IS HOW MANY STORIES SIT THERE NOW. Filled means work is there; a tinted ring means work has been there and moved on; a dashed grey ring means no story has ever entered. That is why the release run reads zero and still shows traffic — nothing sits past QA test passed today, and stories have walked every status through to production. The chip beside each name is that status's own code, unique across the workflow so it identifies exactly one status wherever it is quoted, and coloured by its lifecycle phase so the eight groups still read at a glance. The legend below the diagram spells out all 28. A LINE TAKES THE COLOUR OF THE STATUS IT LEAVES, so a return is traceable to where it came from without following it. The main path is one constant width and the widest thing here; everything off it is thinner and weighted by how many moves took it. A dashed line with no motion is a route the workflow configures that no story has ever taken. Everything that fails, parks or reverts returns to In Triage or To Do, which is why those share one line back rather than six. No duration is shown anywhere on this diagram. 56% of status transitions in this project are zero-elapsed back-fill, so any median would measure when a status was typed rather than when work moved.
03849126056212300000000060005000000
GRGathering requirements
TRIIn Triage
TODOTo Do
DEVIn Development
PRVPeer review
RQAReady for QA
QATQA Testing in process
QAPQA test passed
REGIn regression testing
RSITReady for SIT
DSITDeployed to SIT
RPPReady for PreProd
DPPDeployed to PreProd
ARELApproved for release
SCHScheduled for release
PRODReleased to production
MONMonitoring
CMPComplete
RRVReady for review
IRVIn review
APVApproved
HLDOn hold
REOReopened
QAFQA test failed
REGFRegression failed
SITFSIT failednever used
PPFPreProd failednever used
RBKRollback

Definition38

  • GRGathering requirements0
  • TRIIn Triage38
  • RRVReady for review0
  • IRVIn review0
  • APVApproved0

Ready49

  • TODOTo Do49
  • REOReopened0

Development126

  • DEVIn Development126
  • PRVPeer review0

QA77

  • RQAReady for QA56
  • QATQA Testing in process21
  • QAFQA test failed0

Done29

  • QAPQA test passed23
  • CMPComplete6

SIT & Regression0

  • REGIn regression testing0
  • RSITReady for SIT0
  • DSITDeployed to SIT0
  • REGFRegression failed0
  • SITFSIT failednever used

Pre-production0

  • RPPReady for PreProd0
  • DPPDeployed to PreProd0
  • ARELApproved for release0
  • SCHScheduled for release0
  • PPFPreProd failednever used

Production0

  • PRODReleased to production0
  • MONMonitoring0
  • RBKRollback0

No single phase5

  • HLDOn hold5

User stories only — 324 of them, across the workflow's 28 statuses, with 1,349 moves between them. Task and Technical Task run a workflow with no test gates and are counted in the bar above but not here. The number in a circle is how many sit there NOW, not how many have passed through. Each chip is that status's own code, unique across the workflow so it can be quoted elsewhere, and coloured by its lifecycle phase. 65 moves went backwards and 63 left the road for a parked, failed or reverted state; every one of those returns to In Triage or To Do, which is why they share one line back.

14 stories released to production, 9% of R1 past QAJira

R1 — 0% past QA
QA passed, not released
Counts user stories at the last lifecycle phase. Some have since been released and the Summary carries that count, but this bar measures work that cleared development and test, not work that left the release chain.

0 of 4

R2 — 0% past QA
QA passed, not released
Counts user stories at the last lifecycle phase. Some have since been released and the Summary carries that count, but this bar measures work that cleared development and test, not work that left the release chain.

0 of 31

R3 — 0% past QA
QA passed, not released
Counts user stories at the last lifecycle phase. Some have since been released and the Summary carries that count, but this bar measures work that cleared development and test, not work that left the release chain.

0 of 36

0 carry no release

In none of these bars, and counted in the page total rather than distributed by guess.

The 2 epics carrying the most unfinished work
Ranked by open children, not by percentage
An epic at 20% with four children is a rounding error. Furthest phase reached is computed from the children IN SCOPE, so narrowing to a release changes it. Childless epics are excluded: a list about where the work is cannot be padded with epics carrying none.

The 2 epics with the most unfinished work, of 2 carrying any. 3 user stories are open across all of them.

An epic’s children here are its stories. The technical tasks beneath them are not counted, so this ranks epics by outstanding scope rather than by work remaining.

EpicSquadOpenChildrenQA passedFurthest phase reached
NILE-184Dashboard - Landing Page (MOCK)VA220%Development
NILE-185Dashboard - Level 1 Navigation Menu (MOCK)VA110%Development

Sprint deliveryJira

Scope, reconciled · from Jira
An identity, not four measurements
Start plus added minus removed equals final, and it holds because added and removed are defined from the two boundary states rather than from raw join and leave events. An item that left and came back is committed scope that churned, not new scope. A build where they do not add up fails rather than renders.
Completed so far · from Jira
Counted from the completion date
Not the Sprint field. Stories are bulk-moved onto the active sprint, so the field would credit old completions to whichever sprint is running now.

0of 4 in scope

Sprint 18 is still running.

7 of the 16 open R1 activities are behind their own line, and ARB approved for Payments & Transfers is 55 points behind itManual entry

Where each release stands
Read a row across; the counts do not compare down
Within one kind of work the unit is the same in every release, so R1 build and R2 build compare. The COUNTS do not compare down a column: test cases run in the thousands where solution designs run in the tens, which is why there is no total. The SHARES do, and the bar draws the share rather than the count.
Kind of workRelease 1Release 2Release 3
Elaboration712 of 712100%348 of 44079%not started
Design gate86 of 12370%not startednot started
Build589 of 75578%not startednot started
Platform APIs0 of 50%not startednot started
Test cases4,332 of 6,19470%not startednot started
What was committed, and what arrived
Commitment against delivery, one kind of work per chart
The outline is what the squad signed up to at the start of the sprint; the solid bar is what it delivered. One kind of work per chart, because the units differ. Sprints are not slices of a total: work not finished is committed again next sprint, so these columns must never be added up.

Committed at the start of each sprint against what arrived. Both charts share one scale, so a bar in either stands for the same number of items.

CommittedDelivered

Build

12345678910111213141516171819

Design gate

131415161718
What is still open, and when it is due
Progress against the plan’s own line
Only activities incomplete against their own plan, grouped by the revised target they are working to. The gap is the share delivered minus the share of that activity’s window that has gone, both from the plan. An activity with no committed sprint has no window and shows no gap rather than a made-up one.

2026-09-014 of 6 behind their line

  1. ARB approvedP&Twell behind
  2. Experience APIsP&Twell behind
  3. Integration APIsP&Tbehind
  4. Front-end screensP&Tbehind
  5. Test casesP&Ton its line
  6. Test casesCLahead

2026-09-263 of 10 behind their line

  1. Experience APIsEDBwell behind
  2. ARB approvedCLbehind
  3. Integration APIsEDBbehind
  4. Experience APIsCLon its line
  5. Cyber reviewedCLon its line
  6. Front-end screensEDBahead
  7. Integration APIsCLahead
  8. Test casesEDBahead
  9. ARB approvedEDBahead
  10. Platform APIs: NICLno window

Measured against the plan’s own line. The bar is the share delivered; the tick is the share of that activity's own window that has gone, from its first committed sprint to its revised target. Both come from the plan. The gap between them is the number. The only judgement is where it becomes a word: behind past 5 points, well behind past 20.

Every activity the plan tracks
Delivered of committed, and what a dash means
On one sprint a cell reads as what the squad committed to on day one against what it finished. On all sprints it reads as progress against the whole plan. Over 100% is real and is not capped: a squad can finish more than it committed to. A dash is a row the plan holds with nothing committed; a dot is a row the squad does not have.
ActivityEveryday BankingCards & LendingPayments & TransfersValue Add
Elaboration
Regulatory review143 of 143 100%125 of 125 100%75 of 75 100%13 of 13 100%
UI/UX and customer journey29 of 29 100%31 of 31 100%15 of 15 100%3 of 3 100%
User stories114 of 114 100%94 of 94 100%60 of 60 100%10 of 10 100%
Design gate
ARB approved8 of 11 73%4 of 22 18%1 of 8 13%
Cyber reviewed11 of 11 100%13 of 22 59%8 of 8 100%
Solution design finalised11 of 11 100%22 of 22 100%8 of 8 100%
Build
Experience APIs37 of 71 52%18 of 22 82%42 of 63 67%
Front-end screens150 of 168 89%144 of 144 100%84 of 109 77%17 of 17 100%
Integration APIs27 of 62 44%47 of 64 73%23 of 35 66%
Platform APIs
Platform APIs: NI·0 of 5 0%·
Platform APIs: Payment Hub···
Platform APIs: T24··
Platform APIs: TPH···
Test cases
Test cases1,528 of 2,301 66%1,519 of 1,984 77%1,285 of 1,909 67%
Test cases including the deep layer

Squad and activity totals, not individual artefacts. The source is an aggregate grid, so this section cannot be drilled into.

PredictabilityJira

Carry-over
All three conditions, on a completed sprint
In the sprint’s final scope, not finished when it ended, and in a later sprint. Not “in more than one sprint” — a story can sit in two because someone corrected a field. Measured on completed sprints only: in a running sprint nothing has moved on yet and the figure reads near zero, which says carry-over is solved.

0%0 of 0 in sprint 17 scope

Not enough completed sprints yet to show a trend.

Commitment reliability
Two denominators, named
Of completed user stories carrying a due date, the share that finished on or before it; stories completed without one are excluded from both halves rather than counted as met. The headline is every completed story to date and the line is each sprint’s own completions, so the endpoint and the figure above it are different measurements. At this population both denominators are small, so a single story moves the percentage a long way.

0%0 of 0 completed with a due date

Not enough completed sprints yet to show a trend.

0 of 0 completed items carry a due date. The line is each sprint's own completions, the figure above is every completed item to date.

10% of work that reached Development came back to itJira

Development rework
Phase re-entries, not status hops
A move between two Development statuses is work continuing, not rework. The denominator is user stories that ever reached Development, so leaving work in Definition cannot improve the figure.

0%0 of 2 that reached Development

Nothing is ranked for attention, and why

Waiting on declared thresholds, not on build time. Solution Design’s 14 and 30-day bands are that page’s, not this one’s.

Where work is waiting, and why the dwell column is empty
Why the dwell column is empty
Median days in phase is not shown. 56% of status transitions in this project are zero-elapsed back-fill, so the figure would measure when a status was typed rather than when work moved.
PhaseItemsMedian days
Definition1
Ready1
Development2
QA0
SIT & Regression0
Pre-production0
Released to production0
QA passed0

Median days in phase is not shown. 56% of status transitions in this project are zero-elapsed back-fill, so the figure would measure when a status was typed rather than when work moved.

45 stories blocked, 21 of them from outside the four squadsJira

Blocked stories

0

unfinished stories on the receiving end of a link

Held by their own squad

0

a sequencing problem inside one team

Held by another squad

0

the only cross-squad constraint recorded

Held from outside the four

0

Integration, Workflow & Decision Engine, or work this page does not report

Who records dependencies, and who does not
Stories, not links, and coverage beside the count
Blocked means an unfinished user story on the receiving end of a Blocks or Depends link; Relates is narrative association and is excluded. One story held by four tickets is one thing to unblock — an earlier draft counted edges and overstated it by half. What does the blocking is counted whatever its type, because a story is usually held up by a technical task. A squad recording no links looks unblocked, which is why coverage is a column rather than a note.

0 unfinished user stories are blocked, by 0 links. No squad blocks another squad’s work, so there is no cross-squad matrix to draw.

SquadOpen storiesWith any linkLink coverageBlocked
Value Add400%not recorded

Value Add records no issue links at all, so an empty blocked figure means not recorded rather than not blocked.

InventoryJira

Filtering changes nothing above
This register lists the same user stories the sections above measure, so a row here is a row in every figure on the page. Narrowing it is display, never derivation: no figure above recomputes, and the count states how many of the population are showing so a filtered view cannot be mistaken for the whole.

Showing all 4 user stories.

KeySummarySquadPhaseStatusSprintReleaseDue
NILE-3294Profile & Settings - Security And Preferences - Manage NotificationsProfile & Settings - Settings and Preferences (MOCK)VAReadyTo Do18R1
NILE-4324Dashboard Landing PageDashboard - Landing Page (MOCK)VADevelopmentIn Development18R12026-05-21
NILE-4325Dashboard - Header FunctionalitiesDashboard - Landing Page (MOCK)VADefinitionIn Triage18R12026-05-21
NILE-4326Dashboard - Bottom L1 NavigationDashboard - Level 1 Navigation Menu (MOCK)VADevelopmentIn Development18R12026-06-04

User stories in Core Delivery, the same population the workflow above is drawn from. Tasks and technical tasks run a workflow with no test gates and are not counted anywhere on this page. “All Board Work” needs the items the task rule turns away, which delivery.csv does not carry.