首先提个问题，如果你给某个餐厅写用户故事，用户的动作是写成“点菜”？还是“创建订单”？
这篇文章还是来自Joe Schofield先生，他讲了很多人关心的实践：如何写用户故事？故事应该写到什么程度？是否有写故事的标准？
为什么聚焦Scrum与故事？
很多组织的开发方式，都在由“预测性”向“适应性”转型。国外的统计数据是，66%的敏捷团队选择了Scrum，15%的团队使用带看板的Scrum或者XP。
团队放弃Scrum的原因主要有两个：原因一，是可以不使用“时间盒”。Schofield又对西方软件研发文化进行了讽刺：一旦发现完成不了工作，团队就会持续“改进”时间盒。原因二，则是“按需发布”。
尽管有很多的批评和质疑，Scrum及其“变体”的使用量还是其他敏捷框架总和的8倍。
所以，无论是软件的功能与非功能的规模度量，我们关注的对象都是“故事”。
用功能点的思路写故事
在2018年，Schofield先生建议用“基本过程”的思路来写用户故事。基本过程，在功能规模度量方法（FPA）中有着明确的标准，其含义是用户可以感知的最小活动单元。大家可以参考我以前的文章。
如此有以下优点：
1、用业务语言来写故事，而不是技术实现的细节。就像是本文开头的描述，“点菜”是业务需求，“创建订单”是技术实现。在写故事的时候，应该尽量避免出现“增/删/改/查”的词语——这些都是完成故事所需的“任务”，可以在sprint计划的时候再出现。
2、我们常见的且麻烦的问题就是——故事要分解到多“细”？引入“基本过程”的概念，可以明确回答此问题。不必要的分解不是精益，也不是在遵循第10条敏捷原则。
3、可以促进功能“复用”。
4、故事很容易被度量，转换为规模数字。
5、故事足够小（且不能再小），避免有些团队抱怨说故事“太大”了。
6、通过严谨的“验收标准”，可以清晰地定义故事的“完成”。
7、数据功能可以包含在故事里，也可以在“验收标准”里。这一点，给了我启发，无论是用例（use case）还是用户故事，传统的做法都是忽略了数据模型。但是，我们为什么不把数据模型加进来呢？
8、故事的验收标准还可以包含“非功能需求”。
9、团队可以收集更多的规模数据：故事点、功能点，甚至用例点。可以建立数学模型来分析几者之间的关系。
用“非功能需求”来写验收标准
首先普及一下，对于“非功能性的度量”，目前也有国际标准（IEEE）了，简称SNAP。
上一段，好几条都是关于“验收标准”（AC），这个标准（criteria）可以看成是故事的一个基本的、必须的“属性”。如果故事没有验收标准，那就说明其没有准备好，不能够进入sprint。
PO在接受（或拒绝）故事的时候，应该同时看故事与验收标准的表现情况。
业界的常见做法是将验收标准合并到“完成定义”（DoD）中，包含了功能与非功能需求。如此即可以代表生产者进行核实（verify），也可以代表消费者进行确认（validate）。
在非功能度量的标准中，很多条款都适用于验收标准。如此，故事的非标准功能规模也可以被数字化了。
