VeloWiseengineering delivery intelligence

VeloWise features

Delivery intelligence you can see.

See what changed in the sprint, where work is waiting and what actually reached production. Explore the example reports below: each connects a delivery signal to the question worth asking next. New to the concepts? Start with engineering delivery intelligence.

Watch how VeloWise works in under a minute

  • Sprint intelligence

    Did the sprint deliver what it committed to?

    Original commitment, work added and removed, completed and released work side by side — plus live sprint progress showing which issues put the plan at risk.

    sprint report guideHow commitment is measured

    Sprint health · a 10-day exampleExample delivery data
    Original commitment
    40
    Added scope
    +8
    Removed scope
    −2
    Completed
    18
    Remaining work
    28
    Carryover at sprint start
    12
    Time elapsed50%
    Work completed39%

    Completed / current scope: 18 / 46 issues.

    Half the time has elapsed, but scope has grown by 6 issues. Completion alone hides that change.

    Carry-in is included in the original commitment. Time is context, not a linear delivery forecast.

  • Carryover analysis

    Why did work move to the next sprint?

    Carryover grouped by the delivery stage each issue was in at sprint close — development, code review, QA or release — and the issues that keep carrying sprint after sprint.

    Sprint carryover guideStage at sprint close, explained

    Carryover · the next sprint inherits the workExample delivery data
    1. 12 issuesSprint 1 → Sprint 2Unfinished at close
    2. 19 issuesSprint 2 → Sprint 37 more than last close
    3. 8 issuesSprint 3 → Sprint 411 fewer than last close

    Inherited work competes with new commitments. These are separate sprint-close counts, not 39 unique issues; follow repeat carryover to find persistent delivery debt.

  • Bottleneck analysis

    Where is work accumulating?

    Current queues in each workflow stage compared with that stage’s own history, so a growing review or QA queue stands out without arbitrary red/amber/green thresholds.

    delivery bottleneck analysis guideHow stage queues are compared

    Queue pressure · issues now vs usualExample delivery data
    • Engineering8historical median 9
    • Code review5historical median 4
    • QA/Test16historical median 6
    • Waiting for requirements4historical median 2
    • Blocked3historical median 2
    • Ready for release7historical median 5

    now historical median for this point in a sprint

    Independent example. Mutually exclusive stage counts; a large queue is a signal to investigate, not proof of its cause.

    QA holds 16 issues against a usual 6. Investigate the queue before asking engineering to start more work.

  • Epic delivery

    Is the initiative actually reaching production?

    Epic progress by delivery stage — in development, code review, QA/test, done and awaiting release, and released — so “done” is never mistaken for delivered.

    initiative progress report guideHow epic milestones are counted

    Initiatives · progress toward productionExample delivery data

    Engineering → QA/Test → Done → Released

    Application Workflow21/50 released

    • Not started 1
    • Engineering 8
    • QA/Test 7
    • Done, awaiting release 13
    • Released 21

    Reporting10/36 released

    • Not started 2
    • Engineering 10
    • QA/Test 7
    • Done, awaiting release 7
    • Released 10

    User Management19/25 released

    • Not started 0
    • Engineering 2
    • QA/Test 1
    • Done, awaiting release 3
    • Released 19

    Done is not Released. Application Workflow has 13 finished issues still waiting to reach production.

  • Requirements quality

    Which stories will raise questions mid-sprint?

    Stories and bugs checked for acceptance criteria, actor, expected behaviour, error handling, edge cases and testability — with the evidence for every flag.

    Requirements quality guideHow requirement signals are detected

    An upstream gap can become a downstream delayExample delivery data
    1. Requirement gapRefund behavior unspecified
    2. ClarificationProduct decision needed
    3. ReworkImplementation changes
    4. Testing delayScenarios rerun
    5. CarryoverWork crosses sprint close

    A possible chain, not an automatic diagnosis. Inspect the requirement and history before attributing a delay to engineering.

  • Capacity and commitment

    How much can the team realistically take on?

    Historical throughput ranges, inherited work in progress and typical scope growth, with a simulator to test a proposed commitment before the sprint starts.

    Sprint capacity planning guideCommitment vs delivery method

    What the next sprint can holdExample delivery data
    Next sprint demand24 carried in44 new
    Typically completed57 (median, last 6 sprints)

    68 issues of demand against 57 typically completed: about 11 more than the team has recently delivered — before any interrupts.

  • Scope change

    How much did the plan change after the sprint started?

    Work added and removed after sprint start, reconstructed from change history where available and labelled as a lower bound where it is not.

    Sprint scope creep guideHow scope change is reconstructed

    Scope change · the plan has a historyExample delivery data
    1. Day 140 issuesOriginal scope
    2. Day 3+8Urgent work added
    3. Day 5−2Deprioritized work removed
    4. Day 8+2New requirement added

    40 original + 10 added − 2 removed = 48 current issues. The team delivered against a changing plan.

  • Cycle time and aging work

    How long does work take, and what is getting old?

    Cycle time percentiles instead of averages, and the age of in-progress work compared with how long similar work usually takes.

    Aging WIP guideHow work age is compared

    Count vs ageExample delivery data

    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.

The leadership view: what changed, and what needs attention?

Bring the signals together in an executive summary, without turning the update into a ticket review.

Leadership briefing · questions with evidenceExample delivery data
Are we on track?
  • Day 5: 50% of time elapsed, 18 of 46 issues complete. Review remaining work; this is not a forecast.
What changed?
  • 8 issues added and 2 removed. The original 40-issue plan now contains 46.
Where is work stuck?
  • In the queue example, QA has 16 issues against its historical median of 6.
What is actually released?
  • Application Workflow: 21 of 50 issues released; another 13 are Done but unreleased.
What is likely to carry over?
  • Review aging and blocked work first. Remaining work is exposure, not a predicted carryover count.
Which initiatives need attention?
  • Application Workflow needs a release-readiness conversation. Check the reason for the 13-issue gap.

Illustrative briefing combining the examples on this page. A useful leadership update explains the change and the next question, not just the percentage.

Follow a delivery question from signal to cause

The reports are designed to be read together. Two common paths through them:

  1. Why did we miss the sprint? Start with carryover by delivery stage, check how it is calculated in the carryover methodology, look for the stage where work accumulates with bottleneck analysis, then plan the next sprint with sprint intelligence.
  2. Is work bouncing back from QA? Review requirements quality, see how signals are detected in the requirements methodology, and connect them to delivery risk in why sprints fail.

Evidence you can inspect, not a score to trust

Every conclusion is labelled observed, inferred or unavailable depending on what your export can support. A standard delivery data file has no status history, so VeloWise says when a question needs more data instead of drawing a convincing but invented chart. The methodology documents every formula and threshold, and status names are mapped to delivery stages you can review and change.

Your data, your choice of storage

delivery data files are parsed and analyzed in your browser. Signed out, datasets stay in browser storage. With an organization project, imports are also stored for its members, protected by database-level access rules. Read the privacy model, security and organization access and data storage and deletion pages for the details.

Learn the metrics first

The engineering delivery guides explain each metric, how to calculate it from delivery data and what not to conclude from it — useful whether or not you use VeloWise.

Start with a sample or your own export

Import a delivery data file and analyze it in your browser. You can explore the synthetic sample project first.

Analyze your delivery data