Here's a uncomfortable truth: most of the time a feature is "in progress," nobody is actually working on it.
A ticket moves from "To Do" to "In Progress" on Monday. It gets deployed on Friday. Five days of lead time. But how much of that was actual work?
When you measure, it's often shockingly low:
- 4 hours of coding
- 2 hours of code review
- 1 hour of QA
- 8 hours of deployment pipeline
Total active time: 15 hours. Total calendar time: 40 hours.
That's 37.5% flow efficiency. The other 62.5%—25 hours—was waiting. Waiting for review. Waiting for CI. Waiting for deploy windows. Waiting for someone to pick up the next step.
This is the "dark matter" of software delivery: invisible delays that don't show up in any individual metric but dominate your actual cycle time.
Measuring Flow Efficiency
Flow efficiency is simple to calculate:
Flow Efficiency = Active Work Time / Total Lead Time × 100
But it's hard to measure, because "active work time" isn't automatically tracked. You need to reconstruct it from signals:
Signal 1: Commit Activity
When developers are actually coding, they're committing. Gaps between commits indicate waiting or context-switching.
A ticket with commits at 9am, 11am, and then not again until 2pm the next day has a visible 27-hour gap. What happened in between?
Signal 2: Status Transitions
Jira status changes mark handoffs. "In Review" to "Approved" might take 4 hours of calendar time. Was that 4 hours of active review, or 10 minutes of review and 3 hours 50 minutes of waiting for someone to start?
Signal 3: PR Timeline
GitHub PRs have detailed timestamps:
- PR opened
- First review
- Each comment/response
- Approval
- Merge
The gaps between these events are wait states.
Where Work Waits
In most organizations, the same bottlenecks appear repeatedly:
Wait State 1: Review Pickup
The PR is ready. It sits in the queue. Reviewers are busy with their own work.
Symptom: Long time between "PR opened" and "first review comment."
Typical efficiency loss: 20-40% of cycle time.
Fix: Dedicated review time blocks. Review rotation. Smaller PRs that are easier to pick up.
Wait State 2: Review Response
Reviewer leaves comments. Author doesn't respond immediately because they've moved on to the next task.
Symptom: Long gaps between review rounds. Multiple days with back-and-forth that should take hours.
Typical efficiency loss: 10-25% of cycle time.
Fix: Prioritize addressing review comments over starting new work. The PR in review is inventory—clear it before creating more.
Wait State 3: CI/CD Pipeline
Tests run slowly. Flaky tests require reruns. Merge queues back up.
Symptom: Approved PRs wait hours (or longer) to merge.
Typical efficiency loss: 5-20% of cycle time.
Fix: Invest in faster tests. Fix flaky tests ruthlessly. Parallelize pipelines.
Wait State 4: Environment Availability
Work can't proceed because staging is broken, or shared resources are locked, or someone else's failed deploy is blocking.
Symptom: Work-in-progress tickets with no activity.
Typical efficiency loss: 5-15% of cycle time.
Fix: Isolated environments per developer/branch. Better environment management.
Wait State 5: External Dependencies
Waiting for another team. Waiting for API access. Waiting for design review. Waiting for legal/security approval.
Symptom: Tickets stuck in "blocked" status, or developers switching to other work while waiting.
Typical efficiency loss: Highly variable—can dominate cycle time for some work.
Fix: Better upstream planning. SLAs with dependent teams. Reducing coupling between teams.
Visualizing Flow
Velocinator provides flow visualization that shows where work spends its time:
The Flow Timeline
For each ticket, see a horizontal bar showing:
- Green segments: active work (commits, PR activity)
- Gray segments: waiting (gaps between activity)
- Red segments: blocked (explicit blocked status)
At a glance, you can see if a 5-day ticket was 5 days of work or 1 day of work spread across 5 days.
The Wait State Breakdown
Aggregate view showing where time is lost across all tickets:
- Average wait before review: 12 hours
- Average review-to-merge time: 6 hours
- Average time in blocked status: 4 hours
This tells you which wait state to attack first.
Flow Efficiency Trend
Track flow efficiency over time. As you eliminate bottlenecks, efficiency should improve. A healthy team might see 40-60% flow efficiency; elite teams reach 70%+.
Improving Flow Efficiency
Strategy 1: Reduce Batch Size
Smaller tickets and smaller PRs move through the system faster. Less wait time at each stage.
If your average ticket takes 5 days with 37% flow efficiency, and you break it into 3 smaller tickets that each take 2 days with 50% flow efficiency, you've improved both speed and efficiency.
Strategy 2: Limit Work in Progress
The more work in progress, the more context-switching and the more things waiting at each bottleneck.
Set WIP limits: "No developer should have more than 2 items in progress simultaneously." This forces completion before new starts.
Strategy 3: Swarm on Blockers
When work is blocked, make it the team's top priority to unblock it. Don't just flag it and move on—the blocked work is inventory accumulating carrying costs.
Strategy 4: Automate Handoffs
Every manual handoff is a wait state. Automate where possible:
- Auto-assign reviewers when PR is opened
- Auto-notify when review is needed
- Auto-merge when approved and green
- Auto-deploy when merged
Strategy 5: Measure and Discuss
Put flow efficiency on your team dashboard. Discuss it in retrospectives. "Our flow efficiency dropped to 30% this sprint—what happened?"
Make the dark matter visible, and teams naturally work to eliminate it.
The ROI of Flow Efficiency
Improving flow efficiency is often the highest-leverage investment an engineering team can make.
Consider:
- 10 engineers
- $1.5M fully-loaded annual cost
- 30% flow efficiency → $450K of "active" work
- Improve to 50% flow efficiency → $750K of "active" work
That's $300K of additional effective capacity without hiring anyone. It's not literally that simple, but the direction is right: reducing wait states is cheaper than hiring more people.
Start Measuring
You can't improve what you can't see. Connect your Jira and GitHub to Velocinator, and flow efficiency analysis becomes automatic.
Find the dark matter. Eliminate the wait states. Watch your cycle time compress even as your team stays the same size.
