基于PMBoK、Prince2、CMMI等传统项目管理的公司对吞吐率（Throughput） 的了解相对较少。但是，我确信随着精益概念的不断延伸，吞吐率将受到更多的关注。
吞吐率 是指在一段确定的时间内（如周、月、季度）已交付的工作项的数量.
我们所讲的已交付实际上指已经完成并可能已经交付给顾客。即，在这个过程之后收到了钱。
为了理解吞吐率的概念，我们假设在过去的五周中，某个团队在每周分别交付了4、6、4、2、3个故事。对于已经开始但尚未结束的故事不计入其中。
这五周的平均吞吐率约为 (4+6+4+2+3)/5 = 4 个故事/周。标准偏差约为1个故事/周。
吞吐率基于团队交付能力的真实数据。吞吐率的变化（Throughput variability） 反映了故事大小、复杂性、紧急程度和人员技能等因素的影响。
吞吐率可用于做计划。 继续上面的例子，团队可以在不对单个故事进行任何详细估算的情况下，估算他们的吞吐率（交付率, delivery rate）为 4±1 个故事/周。
然而，在看板方法中，吞吐率主要用于记录团队性能（performance）。逻辑上，目标是为了对吞吐率进行持续改善。
吞吐率是团队在某一确定时间段内（例如周、月）交付工作项数量的能力，以此来保持团队在可承受的负荷下开展工作。
吞吐率不是速率（velocity）
吞吐率类似于敏捷中的速率（velocity）数据，但是它们并不相同。
极限编程（eXtreme Programming）和Scrum中所度量的速率，展示了团队在每个迭代或sprint中可以完成工作的多少，通常以故事点来计。
回到前面例子中的团队，假设最后两周中交付了五个用户故事，故事点数分别为3、4、1、5和3。
那么2周的冲刺（Sprint）中可以完成的故事点总数是 3 + 4 + 1 + 5 + 3 = 16。也就是说团队每个冲刺的速率是16个故事点。
故事复杂度、故事大小、变更、团队技能水平等因素也会造成速率的变化。
敏捷团队使用平均速率来估算在未来的冲刺中能够交付多少功能。然而，他们仍然必须要估算每个单独的用户故事才能确定sprint backlog（范围）。
因此，虽然速率与速度相关，但本质上是一个团队在一段固定的时间内（迭代或冲刺）可以承受的负载，通常以故事点数来计。
吞吐率和资源估算
吞吐率可以用于估算资源。
根据里特定律（Little’s Law）
如果一个团队保持稳定的工作步伐，那么某一特定工作类型或服务分类的平均交付时间（delivery time ，即前置时间、lead time）可以认为是一个常量。
交付率（吞吐率）是为了满足客户可接受的最后交付期限所需要达到的目标速率。
基于此，我们计算出期间需要处理的工作项数量。
例如，若一个故事的前置时间是0.25周、目标交付率是20个故事/周。则，
WIP = 20 * 0.25 = 5 个故事。
若每个人只能处理一个单独的故事，那么我们至少需要5个人才能按时完成任务。出于安全考虑（这里没有精确的公式），我们最好组建一个6人团队来开展工作。:-)
里特定律和吞吐率让我们能够估算开展一项工作所需的资源。
总之，吞吐率易于收集。由于吞吐率能够使你一直专注于团队的性能（performance），因此它是一种有价值的度量。此外，在故事或需求被拆分为相当小的尺寸的前提下，了解团队吞吐率能够减少估算故事或需求所需的工作量。 再者，根据里特定律，吞吐率让我们能够估算在客户期望时间内完成一项指定任务所需的资源。