Below is a cycle time histogram for 100 completed items from a single team — features, bugs, and hotfixes mixed into one view. Use the filter to separate them by type.
-
Start with all types selectedbimodal — two populations
Two humps with a valley between them: two populations mixed into one view. The median of 5 days falls in the gap and doesn’t describe any single item type accurately.
-
Switch to Featureunimodal — peaks at 9–10 days
Features follow a full pipeline: design input, development, review, QA, release. One clear peak, a short right tail for larger pieces of work. A median of 9 days is a useful scheduling signal for this type.
-
Switch to Bugunimodal — peaks at 3–4 days
Bugs skip design. The flow path is shorter and the distribution tighter. Using the combined median to forecast a bug fix would overstate delivery time by roughly 5 days and the 85th percentile by a similar margin.
-
Switch to Hotfixunimodal — most under 2 days
Hotfixes bypass the queue and most pipeline stages. Their short cycle times pull the left side of the combined histogram up, making the bug-and-hotfix hump taller and wider than it should appear when you’re looking at either type alone.
Reading the histogram
The histogram shows what the process has produced for each type: a count of completed items at each cycle time. A stable process tends to produce a similar distribution over time, so the past record is a reasonable model for what will happen next, absent a major process change.
Two numbers matter for scheduling. The median (50th percentile) is the 50% confidence mark — half of historical items completed faster, half slower. The 85th percentile is the point by which 85% of past items completed. For features on this team, the median is 9 days and the 85th percentile is 11 days. A bug fix: median 4 days, 85th percentile 5 days. A hotfix: median 1 day, 85th percentile 2 days.
These numbers answer two scheduling questions. When will it be done? Pick the confidence level and read the corresponding day. At 85%, a stakeholder can point to 85 out of 100 similar past items finishing within that time. When to start? Work backwards from the target date. Release in 11 days. The feature type’s 85th percentile is 11 days. To hit that date at 85% confidence, the item needs to be in the system today. Wait three more days and the team is implicitly working at less than 85% confidence, with no one having acknowledged the shift.
For each candidate item in queue review, check the type, read the 85th percentile, and count back from the target delivery date — that date is the latest safe start. If it has already passed, the conversation is about scope or the release window, not about asking the team to move faster.
Why classify at all
Communication. When a hotfix sits in the review column, everyone scanning the board knows it needs to move fast. Features in review can wait a day; a hotfix can’t. Type carries that priority without a Slack message or a stand-up call. Teams that don’t classify have the same "is this urgent?" conversation item by item that a type label would have settled at a glance. Per-type WIP limits follow the same logic: three slots for features, one for hotfixes, so a production issue always has space without displacing the feature queue.
Output tracking. Counting completed items without type gives a number that explains nothing. A team that closed 15 tickets last week — 10 escaped defects and 5 features — had a very different week from one that closed 15 features. Type breaks down what the system is producing: new capability versus firefighting.
Resourcing load. A feature draws on design, development, review, QA, and a coordinated release. A hotfix needs development and an emergency deploy, bypassing design and formal QA. Three features and two hotfixes in flight make a different demand on design and QA capacity than five features at the same WIP count — knowing which is which lets you see that before a bottleneck forms.
Types define flow paths
A feature needs design input before development starts; a bug can go straight to development; a production hotfix bypasses the queue and skips QA in most teams. Same board, different routes — and different inherent cycle times as a result.
Where a type stalls is also specific. Features stall at the design handoff or at a review slot; bugs stall at reproduction; hotfixes stall at an emergency deploy window.
Classification is also where size and risk are assessed. A feature requiring database migrations and an API change sits in a different risk category from one that adds a UI toggle. Many teams introduce sub-types — feature · small, feature · large — when the distribution for a single type stays wide. The test: does the cycle time distribution become unimodal when you separate it?
There is no standard set of types that works for every team. Stage routing is the first signal for finding natural groupings: if one class of work visits stages another never touches — a design review slot or a security sign-off — they are candidates for different types. The cycle time distribution confirms the grouping. Plot each candidate type separately and check for a single peak. If the distribution stays multimodal, the group contains at least one more natural split. Add types until each produces a unimodal histogram.
The distribution as a diagnostic
A histogram for a single well-classified type should be unimodal — one peak, a tail. When the combined histogram is multimodal, the diagnostic question is whether unlike types have been separated. The valley between peaks marks where two populations differ in characteristic pace; it doesn’t disappear by improving the process, only by splitting the view.
A type that remains multimodal after separation usually contains a hidden sub-type. A bug pool with two peaks is often mixing pre-release defects — found in testing, lower urgency — with production incidents treated as hotfixes. Separating the sub-type resolves the second peak.
A wide or multi-peaked distribution produces a scheduling range too broad to be useful: a median of 4 days and an 85th percentile of 12 days means you can’t commit to either date with confidence.
Escaped defects are not delivery
An escaped defect has a ticket, moves through stages, and completes. Found in production rather than testing, it carries the cost of a quality failure — throughput that adds nothing to planned capability.
Tracking escaped defects as their own type separates them from intentional delivery in throughput and cycle time reporting. A team whose throughput is rising while its escaped defect count is also rising is externalising quality cost to production; the work that looks like delivery is partly rework. Mixed into general metrics, that distinction disappears.
A rising count is a reason to examine the testing stages, not to celebrate throughput. The cost includes the discovery window in production and the rework it triggers — neither of which appears in the cycle time histogram.
Takeaways
- — Classify to communicate, track output, and see resourcing load. A single item count without type answers none of these.
- — Each type follows a distinct flow path. Different stages, different stall points, different inherent cycle times.
- — Use the histogram to answer "when to start". Take the type’s 85th-percentile cycle time, count back from the target delivery date — that’s the latest safe start.
- — A multimodal distribution signals mixed types. Separate them; each should resolve into a unimodal curve. A type that stays multimodal contains a hidden sub-type.
- — Escaped defects are not delivery. Track them separately; a rising count means more quality cost is reaching production.