1. 背景
最近在微信群里，有一些关于用户故事书写的讨论，其中有一些观点
观点1：用户故事的格式不用完全按照标准格式那样，拘泥于形式。
关于格式这一点，不在这里讨论。
观点2：用户故事的 “So that” 必要性不大。
必要性不大的几个理由:
a) 企业已经运作很多年, 赚了很多钱了. (So that 强调的价值, 不大。)
b) 百人级别的产品总监，焦点在哪？ (So that提不起他们的兴趣?)
c) 现实时间点问题:
1) 决策启动时，故事还没写呢, So that放的地方都没有。
2) 后面故事写出来了，决策者总时间不够，不会都看。
d) So that 的东西众所周知
e) So that 陷阱：复述结果而非价值
这么写 PO 自己都发觉
PO似乎发现了什么
2. 为何 So that 必须写？
11
2.1 价值信息传递
从大规模到小团队，价值信息是从上而下，逐层分解、细化而传递的。
So that 承担的, 便是价值信息的载体。省略 So that, 意味着价值信息传送链断裂。
2.2 为下一个级别的故事分解，提供边界。
Epic -> Theme -> Implementable
即使在高层次故事(战略 Epic) 大家对价值都心知肚明了，省略了，下一个层级的故事分解，由于缺乏上一个层级的价值信息，便容易分解偏了。
2.3 为用户故事的优先级排序，提供依据。
在敏捷的世界里，对用户故事进行排序，又是一个众所周知的事情。
那么，排序的依据是什么？相信都能回答 价值。
那么， 价值 在哪？不就是 “So that” 咯。
那么，”So that” 都不见了，排序的依据是否就会是 “感觉” “难易度” 了呢？
2.4 为用户故事的预期与实际效果对比，提供度量方式。
So that 表达的是外部价值，如 “So that 可以提升用户转化效率”,
那么当这个故事上线后，我们就需要获取数据来验证，是否用户转化效率是否提升了？提升了多少？ 与预期是否发生偏差，偏差的愿意是什么。为下一步的改进提供依据。
2.5 为开发人员提供更多信息，避免实现的僵化。
没有明确的外部价值的，可能导致开发人员在实现时，产生不同的行为。
见后面。
3. “So that” 如何写? 又是如何影响开发团队的思考的？
“So that” 关注的应当是外部价值，而不是 “是什么” “做什么”。
还是用上面的例子
这种写法，完全符合用户故事标准，开发会怎么思考？
通过SQL进行检索，把结果呈现出来。
三下五除二，搞定。
But，这个故事，我们如何验证它的价值？ HOW?
验证模糊查询的正确性？验证查询的速度？查询的次数？
如何赚回开发这个功能的成本？
如果换成另一个写法呢？
开发在面对这个故事的时候，除了知道他需要实现查询和呈现，还能知道潜在的，需要记录更多一些信息，以便于后期分析用户购物车的行为。
故事的价值验证，也转变为，购物车(or订单)中的书籍，
有多少是用户通过作者姓名检索后加进来的？
这个功能对成交贡献的提升有多少？
是否还需要添加更多的查询条件？
查询速度是否影响了预期？
…..
用户故事的三段，前面两段都比较好写，可以说稍为引导一下谁都能写。最后的 So that 才是最难的部分，有多少PO在这一步被憋出内伤来啦 😉
但是，但是，So that 部分，才是评价一个PO是否合格的标准。
说了那么多不写So that的理由，其实只有两点:
1. 不愿写
2. 不会写
请认真写好用户故事, 别偷懒
本文作者：周辉庆(Edward Zhou)
拥有20年的软件研发、项目管理与团队管理经验，担任过项目经理、技术总监、CTO、敏捷团队教练等多个职务。具有丰富的TDD，持续集成、ATDD，自动化测试、重构、结对编程、演进式设计, DDD Event Sourcing/CQRS 理论知识与实操经验, 对技术的追求和风趣的工作风格使得他受到开发团队的喜爱，尤其注重工程文化的建设，与一线团队（项目经理、需求分析人员、架构设计人员、 设计开发工程师及测试工程师）打成一片，融入其中。喜欢用各种方法使团队技能得到全方位提升，尤其喜欢使用结对工作的方式使团队迅速体会到敏捷方法与技术实践所带来的挑战和乐趣。
原文链接：https://www.jianshu.com/p/c1d8ac5e75bd
