VeloWiseengineering delivery intelligence

Engineering delivery guides

Each guide explains what a metric means, why it matters, how to calculate it from your delivery data, how to interpret it, common mistakes, and what an engineering manager can do about it — with a worked example. Written for engineering managers, directors and heads of engineering, Scrum Masters, TPMs and product managers.

New to VeloWise? See how VeloWise turns delivery data into an explanation leadership can act on.

See the delivery story before you read the metric

Five worked examples. Each connects a visible signal to a better management question. All numbers are illustrative.

01 · Sprint progress

Same sprint. A different story each day.

Compare time elapsed, completed work and scope changes at Day 1, Day 5 and Day 10. A completion percentage only makes sense when you know which plan it measures.

Understand sprint health →
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.

02 · Carryover

Unfinished does not mean untouched.

Committed work may already have moved through development and code review into QA. At sprint close, that unfinished work carries forward with a different next action at each stage.

Understand carryover by stage →
What carryover isExample delivery data

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
03 · Bottlenecks

The constraint may be after development.

Backlog → Development → Review → QA → Release. Compare each queue with its own history: a growing QA queue calls for a different conversation than a growing engineering queue.

Learn to investigate a queue →
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.

04 · Production delivery

“Done” and “available to customers” are different milestones.

QA, approval and deployment can remain after code is finished. Keep those steps visible so leadership can distinguish implementation progress from production delivery.

Read initiative progress correctly →
Code finished is not value in productionExample delivery data
  1. Engineering completeCode is ready for validation
  2. QA/TestBehavior verified
  3. ApprovalRelease accepted
  4. DeploymentChange shipped
  5. ReleasedAvailable in production

A team may finish engineering before QA and release. This teaching workflow is illustrative: VeloWise uses your configured status mapping and reports Released separately.

05 · Requirement gaps

The delay can begin before the work starts.

Before: “Support refunds.” After: define who can refund, the amount limits, failure behavior and acceptance scenarios. Making the decision earlier can prevent a clarification loop during QA.

Explore requirement signals →
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.

Engineering delivery for leaders

Sprint outcomes, predictability, leadership updates and delivery risk — each guide answers one question leaders ask, with example visuals. Start with Engineering Delivery Intelligence.

Metrics and how to calculate them

Start with the delivery problem

Explore the supporting metrics

Use the guides below to follow a signal into workflow, capacity, scope or epic delivery. Each explains its assumptions and includes a worked example.