How every metric is calculated

Every number in this product comes from a documented, deterministic rule applied to your export. Nothing is generated by a language model, and nothing is estimated when the data cannot support it.

How VeloWise thinks

Each concept below is shown first, then explained. Every figure is example data; the rules are the ones the product applies to your export.

1. 1. Not started
   2. Development
   3. Code review
   4. QA / testing
   5. Done
   6. Released

   • Open
   • To Do
   • Backlog

   Not started

   • In Development
   • In Progress

   Development

   • PR Review
   • Code Review

   Code review

   • Ready for QA
   • In Test
   • UAT

   QA / testing

   • Closed
   • Resolved

   Done

   • Production
   • Deployed

   Released

   Jira statuses (top) differ from team to team. Each maps to one delivery stage, so “work waiting for review” means the same thing everywhere.

   Every team names its Jira statuses differently; mapping them to one delivery model is what makes stages comparable at all.

   Guides that apply this: Engineering bottlenecks, Software delivery metrics, Engineering delivery intelligence

2. Sprint 10 · at close

   • Issue ADone
   • Issue BQA / testing
   • Issue CCode review
   • Issue DDevelopment

   Sprint 11 · starts with

   • Issue BCarryoverwas in QA
   • Issue CCarryoverwas in code review
   • Issue DCarryoverwas in development

   Sprint 10 scope

   20

   Completed

   17

   Carryover

   3

   Carryover is the unfinished work a sprint hands to the next one — and where it was sitting matters more than how much there is.

   3carried over÷20in sprint scope=15%carryover rate

   Carryover rate = carried over ÷ sprint scope = 3 ÷ 20 = 15%

   Guides that apply this: Sprint health, Sprint carryover, Reduce carryover, Jira sprint report, Why work carries over

3. One-time carryover — carried once, then finished

   1. Sprint 10
   2. Sprint 11

   Chronic carryover — carried three sprints in a row

   1. Sprint 8
   2. Sprint 9
   3. Sprint 10
   4. Sprint 11

   An issue that carries once is timing; an issue that carries sprint after sprint is a decision nobody has made.

   Guides that apply this: WIP debt, Epic carryover

4. 1. Sprint 10 endsABC-123Code review
   2. Sprint 11 startsABC-123Carryover
   3. TodayABC-123Released

   Historical carryover analysis

   Why did Sprint 10 carry this over?

   Status at sprint close = Code review

   Current sprint analysis

   Where is our inherited work now?

   Current status = Released

   Why work carried over depends on where it was when the sprint ended — not where it is today.

   Guides that apply this: Engineering delivery intelligence

5. 1. Sprint starts64 issues committed
   2. Day 3+5 added
   3. Day 7+8 added
   4. Day 10+5 added
   5. Sprint ends82 issues in scope

   Original commitment

   64

   Final scope

   82

   Scope growth

   +28%

   58 completed looks like 71% of final scope. Against the plan the team made, and the 18 issues that arrived after it, the story is different.

   Comparing completed work only with final scope hides what happened during the sprint — compare with the original commitment too.

   82 − 64added after start÷64original commitment=+28%scope growth

   Scope growth = (final scope − original commitment) ÷ original commitment = (82 − 64) ÷ 64 = +28%

   Guides that apply this: Sprint health, Sprint scope creep, Jira sprint report, Epic scope creep

6. Team A · 31 unfinished

   Development24

   Code review4

   QA / testing3

   Most unfinished work is still in active development.

   Team B · 48 unfinished

   Development8

   Code review19

   QA / testing21

   Most unfinished work is already downstream, waiting on review or testing.

   Carryover is not automatically an engineering capacity problem — where the unfinished work sits tells you which conversation to have.

   Guides that apply this: Reduce carryover, Why sprints fail, Engineering bottlenecks, Why work carries over

7. Code review · Team A

   0–2 days6

   3–5 days4

   6–10 days8

   10+ days11

   29 issues — and 19 of them older than 5 days.

   Code review · Team B

   0–2 days18

   3–5 days4

   6–10 days1

   10+ days0

   23 issues — nearly all fresh and moving.

   How many issues sit in a stage says little; how long they have been there — against the team’s own history — says a lot.

   Guides that apply this: Aging WIP

8. Sprint 20

   60 → 56gap 4

   Sprint 21

   65 → 57gap 8

   Sprint 22

   72 → 58gap 14

   Sprint 23

   78 → 59gap 19

   • Committed ↑ +18
   • Completed → +3

   When commitment keeps rising and demonstrated throughput does not, carryover follows — plan against what the team has actually completed.

   78committed−58median completed=≈ 20likely to carry

   Expected carryover ≈ commitment − demonstrated throughput = 78 − 58 (median of 56, 57, 58, 59) ≈ 20 issues

   Guides that apply this: Why sprints fail, Capacity vs velocity, Commitment vs capacity, Engineering throughput

9. Business Profile epic

   Development complete

   92%

   QA complete

   68%

   Released

   42%

   Engineering completion ≠ production delivery. Development complete counts work past development; QA complete counts done and released; released counts only what reached production.

   A Jira “% done” can say 92% while only 42% of the epic has reached customers — delivery has milestones after engineering.

   Releasedin production÷In-scopeepic issues=42%production release

   Production release % = released issues ÷ in-scope epic issues (42%); engineering completion = (done + released) ÷ in-scope (68%)

   Guides that apply this: Jira epic progress, Initiative progress, Jira epic reporting

10. Original story

    “As a user, I can update my business.”

    Gaps VeloWise flags

    • Who can update it?
    • Which fields?
    • Validation?
    • Permissions?
    • Audit history?
    • Concurrent changes?
    • Error handling?

    Delivery-ready requirement

    • Actors
    • Permissions
    • Acceptance criteria
    • Validation
    • Edge cases
    • Audit behaviour
    • Test scenarios

    Most requirement-driven delay is visible before development starts, as questions the story does not answer.

    Guides that apply this: Requirements quality

Evidence labels

• Observed Read directly from the export (or the sprint dates you entered).
• Inferred Derived with a stated assumption that could be wrong — the assumption is always shown.
• Unavailable The export does not contain what is needed. The product explains which fields or history would be required.

What a Jira export can support

The change-history file uses one row per field change: Issue Key, Field, From, To, Changed. It is the flattened form of Jira’s issue changelog (/rest/api/3/issue/{key}/changelog), which scripts and marketplace apps can export.

Metric definitions

Thresholds

Classifications use these defaults, which you can change in Data & settings. Bottleneck rules compare a team with its own history, so the defaults control sensitivity rather than encode an industry benchmark.

Executive summary rules

The summary is a fixed set of rules over the calculated metrics: completion of commitment; scope change beyond ±10%; carryover vs the previous closed sprint (changes under 3 points are “steady”); the largest queue at close (at least the minimum sample); stage time vs the previous three sprints (a change of at least 25% and at least one day); throughput vs the recent median (±15%). Recommendations come from contributing factors present in at least 20% of unfinished issues, ranked by how many issues show them.