将用户故事作为可持续的实验
用户故事常常被描述为能够在一个迭代中完成的一小块工作，同时又能带来一些价值。这个描述在开发团队和使用系统的业务部门间造成很多沟通问题。开发团队的主要目标变成创造小块的功能，而不是有价值的功能，结果导致交付了一堆脱离了业主真正关心的事情的小功能，而这些小功能又很少能独自交付生产。这极大地损害了迭代开发的价值。
另一方面，由于很多超出我们控制能力的因素的影响，直线性的计划很少能够奏效。我们应该将计划看做是一系列可持续的实验（survivable experiments）。
用户故事不应该是为了迁就迭代周期而是“小”的，而是因为小的用户故事即使被证明是错的，也不会导致“世界末日”。关于用户故事大小的关键问题不是迭代周期的长短，而是业务持份者愿意做出多大的投资来验证提议中的变化是否能带来预期的收益。
在一个高度确定的市场中，业主能完美地预测未来、没有竞争、整个生态环境完全可控、最终用户的个人想法微不足道，在这样的市场中，迭代开发没有任何业务价值。但是如果以上任何一项不再控制之中，那么可持续的实验加上迭代交付可以将意外的变化转变成竞争优势。
小的用户故事可以帮助产品经理发现真正需要构建的功能，而不会沿着未经验证的假设冲得太远。
通过将用户故事作为可持续的实验，我们可以将注意的焦点从技术复杂性转移到期待的结果和对业务问题的学习上去。这可以避免技术性的故事、业主不关心的故事。
如果有一大块功能要开发，那么就需要识别出背后的假设，然后想出最简单的方法来验证或证伪这些假设。围绕这些假设设计实验、再把实验变成用户故事。以这些实验为基础，再通过小步迭代逐步交付整个大图景的其余部分。
小心那些过于宽泛的角色。
用户故事的最大好处之一是让交付团队从用户的角度思考问题，而不是纯粹只考虑如何构建系统。但是实际应用中有很多用户故事以“作为一个用户”这样来开头。
一个笼统的用户角色（“用户”）无法提供有用的进行讨论的上下文。不考虑特定的用户群，就无法判断拟议中的解决方案正是所需要的，还是不必要的范围蔓延。
书中举了一个例子。某个项目中有一个用户故事“作为一个用户，我希望能通过社交平台的账号登录，这样我就不需要记忆额外的用户名和密码。”表面看这是一个很正常的用户故事。单如果就这样的去实现的话，那么就需要支持Facebook，Twitter，LInkedIn，Google+，OpenID等等。如果是国内的项目，那么就需要支持微信、微博、淘宝、支付宝等等。
再进一步对于“用户”这个泛化的角色进行分析以后，发现能从这个功能中受益的主要是两个用户群体：学校里的老师和学生，由于Goodle Apps for Education在教育机构中非常流行，因此只需要能够支持用GMail账号登录就可以了。而由于很多学校不允许在校内访问Facebook和Twitter，因此连这两个平台也不需要支持。
清晰而准确地描述用户角色有助于我们更好的识别用户的要求并且移除不需要的复杂性。一旦理解了谁将使用我们的产品，才有可能比较不同的解决方案选项，提供替代性的功能、甚至抛弃掉不合适的特性。
另外，定义良好的用户角色对于产品管理和计划策略也非常关键。例如可以根据缩小的用户群来分割用户故事，或者根据对不同用户组的影响来觉得故事的优先级。
对消费类系统来说，用户画像（User personae）是一个非常好的起点。或者根据共同的行为将用户分组。
评估控制区和影响圈
H.William Dettmer 在 《The Logical Process》中提出三个系统区域：
- 控制区：系统中我们可以自己控制变化的部分。
- 影响圈：我们可以影像，但不能完全控制的活动。
- 外部环境：那些我们没有影响力的要素。
一个有益的指导原则是用户希望达到的目标（用户故事中“为了……”部分）最好位于交付团队的“影响圈”内，而期望的功能（用户故事中的“我需要……”部分）最好位于控制区内。这不是一个需要百分百遵守的规则，但是如果有不符合这个模式的用户故事，那么需要仔细地进行检查和斟酌。
如果需要实现一个用户故事（功能？）的目的位于交付团队的控制区内，那么这个故事实际是个没有风险的任务。这样的故事有三种可能性：假故事（fake）、微故事（micro-story）或者误导（misleading）。
假故事是指为了满足开发团队成员的需要提出的，例如QA要求“数据库可以自动重启、以便能更快地进行测试。”
将一个大的业务故事分解为很多细小的片段，就得到了微故事。一些这样的碎片是没有风险的，它们只是达成某些大目标的踏脚石。这些故事可以存在，但不要因为它们而干扰了对更大的故事的跟踪，必须根据微故事组成的更大板块的完成情况来评估微故事的成败。
误导性的用户故事实际是在描述解决方案而不是真正的用户需要。
另一方面来说，如果需要的功能超出控制区的范围，那么可能有两种情形：完全不切实际的期望，以及这个故事不能完全由交付团队来完成。
对于第二种情况可能需要引入外部专家、或者组织中的其它部分来合作完成。
为用户故事添加一个“不迟于”的日期。
在为灵活的范围进行计划的时候，如何处理有时间约束的变更是一大挑战。某些具有完成时间要求的故事在开始时并没有很高的优先级，这样面对多个业务持份者的开发团队在为迭代计划选择用户故事时，容易忽略有时间约束条件的故事，导致最后没有足够的时间来安排这些故事的开发。
应该在一开始就明确这个故事必须完成的最后日期，并将这些故事与Backlog的其它部分分开来管理，以便开发团队能讲它们安排进恰当的迭代中。使用用户故事的一大好处是允许业务部门灵活调整优先级和范围，但这不应该成为忽略已知的时间约束的借口。
但也要担心某些业务持份者滥用这个体系，使自己提出的用户故事实际获得不恰当的高优先级。
总之，要求业务部门提前一段时间提出有时间约束的故事是个好主意。但是也不要把所有的故事都标上一个“不迟于”的日期，这会使所有的故事都变成“紧急”的。