Calculator inputs
Use queue flow assumptions that match your team, sprint, or delivery stream.
Plotly graph
The line below shows how lead time changes as WIP grows at your current throughput.
Example data table
| Scenario | Arrival/day | Effective capacity/day | WIP | Queue | Lead time | Status |
|---|---|---|---|---|---|---|
| Baseline team | 18.0 | 9.37 | 14 | 9 | 2.45 days | Unstable without intake control |
| Reduced arrivals | 8.5 | 9.37 | 10 | 6 | 1.88 days | Healthy flow |
| Lower rework | 9.0 | 10.24 | 10 | 5 | 1.47 days | Healthier capacity margin |
Formula used
Base capacity = service rate per developer × developers.
Effective capacity = base capacity × (1 − rework rate) × (1 − expedite share ÷ 2).
Throughput = minimum of arrival rate and effective capacity.
Cycle time = WIP ÷ throughput.
Wait time = queued items ÷ throughput.
Lead time = cycle time + wait time.
Flow efficiency = active touch time in days ÷ lead time × 100.
Recommended WIP = throughput × target cycle time.
These formulas combine Little's Law with practical software delivery adjustments for rework and expedites.
How to use this calculator
- Enter the daily work arrival rate for your backlog or delivery stream.
- Add the average daily service rate for one developer and the number of contributors.
- Estimate rework and expedite percentages using recent sprint or flow data.
- Enter the current WIP, waiting queue, and average active touch time.
- Set a target item count and target cycle time.
- Press Calculate Q Flow to see results above the form, download CSV or PDF, and review the graph.
FAQs
1) What does Q flow measure in software development?
It measures how work moves through a delivery queue. This page estimates throughput, capacity, utilization, cycle time, wait time, lead time, WIP guidance, and backlog clearance speed from a small set of operational inputs.
2) Why is utilization above 100% dangerous?
When incoming demand exceeds effective capacity, the queue grows. That usually increases lead time, context switching, blocking, and schedule risk. Even brief demand spikes can create long recovery periods once the system becomes saturated.
3) Is Little's Law exact for software teams?
Little's Law is reliable when the system is reasonably stable and measurements use the same boundaries. Real teams still need adjustments for rework, expedites, approvals, and blocked work, which is why this calculator adds practical modifiers.
4) Does expedite work always improve delivery?
Not always. Expedites help urgent cases, but too many urgent items reduce team focus and interrupt normal flow. Overuse often hurts average delivery speed because switching cost consumes capacity that planned work also needs.
5) How do I choose a good WIP limit?
Start from the desired cycle time and current throughput. The calculator uses recommended WIP = throughput × target cycle time. Then review blockers, review delays, and skills coverage before locking a final policy.
6) Can I use story points instead of tickets?
Yes, as long as every input uses the same unit consistently. If arrivals, service rate, WIP, and targets all use story points, the formulas still work. Mixed units will produce misleading results.
7) What if arrival rate changes every week?
Run the calculator with a rolling weekly or monthly average, then compare it with a worst-case week. That gives a practical view of normal flow and stress conditions without assuming demand is perfectly steady.
8) How does rework affect queue flow?
Rework consumes capacity that could finish new items. Higher rework reduces effective throughput, increases utilization, and usually expands both queue time and lead time. Lower defect escape and better review quality typically improve flow quickly.