The number of work items completed per unit of time, counted where work leaves the system rather than where it is started.
Throughput counts finished items per week or per month, which makes it the flow-based counterpart to velocity without requiring an iteration to be denominated in. Because it counts completions rather than starts, it cannot be inflated by beginning more work, and a team that starts twice as much while finishing the same amount sees no movement at all. Throughput is usually read alongside cycle time, the elapsed time from starting one item to finishing it, since the pair tells you both how much is coming out and how long any single request should be expected to take.
See also
Work organised as a continuous pull with no fixed iteration, controlled instead by a limit on how much may be in progress at once.
A cap on how many items may be in progress at once, which forces work to be finished before anything new is started.
The fixed length of the cycle a team plans, works and reviews in. Its value comes from repeating, not from being short.
Where this comes up
Predictive work gets an ending for free, the day the thing is handed over. Iterative work has to manufacture one, which is why so much of it never formally ends at all.
Cadence is the beat the work runs to. Delivery cadence is how often finished output reaches the people who asked for it. Teams conflate the two and then wonder why nobody feels the pace.
Iteration-based agile fixes the length of the cycle and commits a batch to it. Flow-based agile fixes the amount of work in progress and pulls the next item when a slot frees.