GUIDE
Flow Distribution: What It Is and How to Calculate It
A core flow metric — the mix of work a team actually completes, broken down by category.
What it measures
Flow distribution is the proportion of completed work that falls into each category your team tracks — commonly some version of feature work, defects/bugs, technical debt, and risk/compliance work. The Flow Framework defines four official categories; in practice, most teams eventually need a fifth or their own variation, because the original four don't cleanly cover work like recurring operational toil that isn't quite a defect and isn't quite a feature.
How to calculate it
Classify each completed item into a category, then express each category's share as a percentage of total completed work over a period. The part that requires an actual decision is where the category boundaries sit — issue type and labels in your tracker are a starting point, but rarely line up cleanly on their own; most teams end up needing explicit rules (if field X contains Y, it's category Z) to get a breakdown people actually trust.
Why it matters
A single throughput number hides the story flow distribution tells: a team that "shipped 40 items" but where 30 of them were bug fixes is in a very different position than one where 30 were new features. Tracking the split over time turns "we're busy" into "we're spending most of our capacity on defects this quarter" — a starting point for an actual conversation about priorities, not just a vague sense that the team is stretched.
How moasy.tech computes it
moasy.tech classifies completed work into Bug, Feature, Technical Debt, Toil and Risk — five categories instead of the Flow Framework's original four, closer to how engineering teams actually describe their work, including a category ("Toil") for the recurring operational load that doesn't fit neatly as a defect or a feature. Categories come from semantic rules you configure yourself, not a fixed taxonomy: set a company-wide default, then let each team override it, since what counts as Toil for one team can be a Feature for another. The same categorization can also be broken down one level further, by epic, to see which specific initiative is generating the most of any given category.
See the other flow metrics in the full guide, or the complete implementation on the Flow Metrics feature page.
Questions about flow distribution
Why does moasy.tech use 5 categories instead of the Flow Framework's 4?
Because "Toil" — recurring operational work like manual deploys, access requests, or routine maintenance — doesn't map cleanly onto feature, defect, debt or risk, and forcing it into one of those buckets made the breakdown less useful, not more accurate.
Can the same category mean different things on different teams?
Yes, on purpose — a team's own rule takes precedence over a company-wide default, since what one team treats as Toil, another might treat as a Feature, and forcing one fixed definition on every team tends to produce numbers nobody on the ground trusts.