Sprint计划会议的准入是：进入本Sprint的产品Backlog条目已经完成梳理，符合INVEST原则。但在实践中，我们发现这个原则无法直接使用。
我们先看看一般的解释。
一个好的用户故事应该遵循INVEST原则：
- 独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。
- 可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。
- 有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。
- 可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。
- 短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。
- 可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。
如果仅仅从字面意思上看，INVEST好像是用户故事定义和拆分的原则，确实没办法指导冲刺的准入。
如果我们换一个角度，不是从特性解释而是从执行要求的角度，来看待INVEST原则，就可以用于控制迭代的准入：
- 独立性（Independent）— 指的用户故事间的依赖控制程度。在进入迭代前，用户故事间的依赖程度必须是已经解耦到了这样一种程度：可以在一个迭代内实现所有强依赖的用户故事。如果不能在一个迭代内实现所有强依赖的用户故事，则意味着需要对用户故事重新进行定义和拆分。
- 可协商性（Negotiable）— 指的是PO和Team对用户故事已经沟通到基本达成一致理解的程度，Team对用户故事的理解已经基本上没有什么疑问。如果还存在疑问，则说明沟通未达成一致。
- 有价值（Valuable）— 指的对当前所有用户故事的价值，在PO和Team间已经理解达成一致，以便确认下一个迭代的目标和优先级。这里我想特别强调的是PO团队对技术故事的理解，尤其是技术债的理解，须知技术债的修复成本随着时间呈指数增长的。我们往往容易出现的一个问题是：由于非技术出身，PO团队不理解目前产品中已经欠下的技术债，而导致技术债始终无法得到偿还，进而变得修复成本越来越高。在迭代前，PO和团队应该一起审视下技术债的情况，以及确认是否对其价值达成一致。
- 可以估算性（Estimable）— 有两个因素会影响到估算的准确性：故事太大、相关知识的缺乏。如果让我们估算一下一栋大楼的面积，我们很难估算；但是如果让我们估算一下一个房间的面积，我们则会估算得比较准确；所以要确保估算的相对准确，必须控制故事的规模。如果我们对故事的理解存在不足，或者技术实现方案了解不够，同样也会导致估算估算得非常不准。这就要求我们确认故事的规模是否已经足够小，以及确认我们的团队是否已经对故事有足够的了解，并对技术实现方案基本达成一致。
- 短小（Small）— 要进入迭代的故事粒度必须是足够短小的，按照要求是应该能够在1-2天完成。我们应该确认故事的粒度是否已经在此大小范围。
可测试性（Testable）— 可测试性的含义是在明确的输入下有明确的输出，在迭代前我们要确认的是：是否所有用户故事都已经完成测试要点的讨论和整理。
基于以上对INVEST原则的理解，我们就可以整理出迭代准入的准则：
- 独立性（Independent）— 强依赖故事的用户故事，是否可以在一个迭代内同时实现。
- 可协商性（Negotiable）— Team是否理解用户故事，无疑问。
- 有价值（Valuable）— PO团队是否了解当前欠下的技术债的价值。
- 可以估算性（Estimable）— 可能纳入下一个迭代的用户故事是否可以一个迭代内完成；Team是否对技术实现方案已经达成一致理解。
- 短小（Small）— 确定要纳入下一个迭代的用户故事是否可以在1-2天内完成。
- 可测试性（Testable）—确定要纳入下一个迭代的用户故事是否已经完成了测试要点的讨论和整理。
本文作者：
李洁（Jerry Li） ，Scrum中文网资深顾问，CSM，敏捷教练
