用户故事（User Story）没有真正业务价值！”
（熊节对本文亦有特殊贡献）
理论告诉我们：应该从高业务价值Story开始进行迭代，这样我们就有更多的时间对高业务价值的Story发现问题并修复。这句话的后半段是告诉我们为什么要这么做，而后半段成立的前提是，我们假设先做一定可以先发现问题。
根据这个理论我们按照Risk-Value的方式把 Story分散在这个二维区间里面，把最靠近于High Risk和High Value的区域作为优先选择放入第一迭代。但是问题是，我们也许可以很容易分辨一个Story的技术风险，但当每个Story独立存在的时候，衡量它的Story价值是否还能够反应真正的业务价值？
有价值（Valuable）作为故事重要的一个标准之一是我们一再强调的概念——每个用户故事都是有价值的。但是大部分情况，我们的拆分都是将一个流程化的业务场景，转化成许多颗粒度更细但高于功能点的Story，所谓的独立和有价值，只是一种心照不宣的，与程序员之间装载在合适大小包装中的契约（你难道真的天真认为So That里面是所谓业务价值吗？或者说，客户真的按照你So That中的描述，对比他在这个Story上花的钱进行ROI分析决定要不要这个Story吗？如果不是，它就是个与程序员的窃窃私语：“好吧，我至少告诉你做这个不是浪费生命”）——避免太大，整个场景作为一个Story太大，或者避免太小，一个功能点让开发人员不知全貌。可以说这种Story化实际上是“亲开发”的，但对于业务来说，真正产生业务价值的是那个拆分前的场景，而不是我们拆分后的Story。只有当场景下的所有Story被交付，才能产生业务价值。
回到之前的理论，当我们考虑Story的“高业务价值”时，其实我们是一厢情愿。独立存在的Story也许有存在的价值，但绝对还谈不上业务层次上的业务价值，高业务价值是一个“一揽子”的东西，它是若干个“价值”不一的Story的集合，只有当集合被交付的时候，才谈的上业务价值高低。
那么当我们在进行迭代计划的时候，如果按照Value-Risk法计划，势必会出现Value被轻视，我们确实按照技术风险进行计划，但是单个故事的价值不代表最终的业务价值，那么你怎么要求你的客户进行交付签收，实际上你交付的是零散的Story，而并不交付业务价值。如果你没有交付业务价值，那么之前的理论便是个伪命题。
最直接的一个例子是，当敏捷被谈起的时候，我们总是说：先做一个Ugly and Dirty的界面，把高价值的Story先实现，快速上线，收集客户需求进行反馈，然后快速对变化进行响应。但是，没有一个完整的业务场景，或者接近真实的用户界面，客户无法感受完整的业务价值，你如何苛求客户提出改进？我们遇到的情况是，在前4个迭代满是欢愉无比的客户，团队亦轻松无比因为没有太多实质性的反馈，更多的只是纠结字体或者行高这样并不关键的反馈，但是到了发布的后期，随着功能的增多，客户开始体会业务场景的时候，问题逐渐显露出来。我们在抱怨客户不负责没有在较早的时候反馈的时候，我们是不是也要反省下我们自己，也许我们充分考虑到了技术风险，但是，每个迭代交付的都不能称之为“业务价值”，客户何谈反馈？
还有另外一个极端，迭代计划不重视技术风险，按照业务场景，每个迭代完成1个（或两个迭代完成一个）重要程度不同的业务场景，客户按照真实的业务场景来体会业务价值并提供反馈，但这样的做法往往是在一开始便花大功夫投入在UI上，而且极容易忽略技术造成的风险。例如曾经有一个内容管理的系统，迭代计划采取的是按照业务场景区分，因为刚开始的业务场景对Migrated内容的依赖不大，团队并没有对Migrated的内容技术风险有足够认识，导致技术风险在最后才被显现，最终导致项目延期。
那么，迭代计划应该在技术风险和保证有效的反馈及时提出中权衡。既保证技术风险得到很好的重视，又能通过合理的Story交付计划，把独立业务价值通过批量的不同价值大小的用户故事分散在不同迭代，使客户更好感知这样的价值从而提出有效的反馈。
既然如此，我们又如何设计迭代计划使有效的反馈及时出现又使技术风险降到最低：
为迭代写一张卡，而这个迭代的所有Story就是这个迭代卡的AC，完成了所有的Story便实现了迭代卡上所描述的业务价值。因为迭代工作量是趋近于一致，于是尽可能通过拆分保证一个完整的业务价值尽量在一个迭代内完成。而每次的Showcase都按照每个Story的顺序完整串联一个真实的业务场景让客户感知，鼓励其提出真正有效的反馈；
对于被串联的完整业务价值也许不能在单个迭代完成，那么可以考虑酌情拆分，或者通过拆分Story把对于单个业务价值的MMF(Minimal Marketable Features)缩整在一个迭代的内。在前若干个迭代里尽量安排10%到50%的技术Spike(根据项目本身项目技术风险程度而异),在后面的迭代中逐渐把因为技术风险降低的部分，转为对上次迭代交付的完整业务价值进行改进，包括响应客户反馈和变化，以及用户体验增强，并持续预留20%左右的开发量作为对上迭代进行改进，称之为“增益团队”；
对于迭代间的“迭代卡”需要有合理的业务场景串联，目的是让客户体会出敏捷“特性增益”的目标，并且这样的增益一定是基于业务的，而不是简单的功能添加；
技术风险一旦识别必须作为第一优先级进行处理，并在迭代计划会议上及时提出，合理安排工作量——这也是为什么在若干迭代之后长期保证20%左右的“增益团队”，随时调整这部分额外工作量到技术风险相关的Spike上去，并保证足量的技术知识传递；
明确Tech Lead的职责，由其全权负责项目风险掌控，以及团队技术能力提升的工作，甚至不需要负责开发；
敏捷开发的迭代期如果不加以设计和控制，而任其发展，认为敏捷是不重流程的，很容易出现项目开始的前若干个迭代一帆风顺，结果在项目结束前集中爆发，爆发的问题要么是“做了错的软件”——客户反馈未及时反馈；要么是“做了不可用或者不好用的软件”——技术风险未及时发现。
总而言之，一个好的迭代计划，除了要真实反应团队交付能力以及交付节奏之外，从控制风险角度上来说，还应该，一帮助客户反馈有效改进建议；二帮助及时发现技术风险。