一、工作故事模板
要明白工作故事如何将重点从用户转移到要完成的工作，让我们看一下推荐的工作故事模板：
与普通用户故事模板一样，工作故事模板也由三个部分组成。第一部分被称为“情境（Situation）”，该部分紧随模板中的When一词，提供有关何时执行故事或触发故事原因的“上下文（Context）”。例如：
当提交订单后…
当通过邮政编码搜索时…
当找不到匹配项时...
当查看最近的订单时...
工作故事第二个元素的模板是“我想要（I want to）”，该元素提供了故事的“动机（motivation）”，动机可以当做用户的既定目标或首要目标。
例如，我想在今晚晚餐时吃披萨。为什么今晚要吃披萨呢？因为我今晚要跟一些朋友看足球比赛，披萨饼可以满足不同饮食需求和偏好的人。在工作故事的世界，容易提供一组被称为“预期结果（expected outcome）”的元素，使之遵循工作故事第三个模板“这样我可以（so I can）”。
把我对披萨的渴望变成一个工作故事：
当今晚晚餐时，我想吃披萨，这样我就可以轻松喂饱我的朋友们。
这不是一个特别完美的工作故事，但它说明了用户“动机（motivation）”与“预期结果（expected outcome）”之间的差异。
二、工作故事和用户故事对比
要找出工作故事可能比用户故事更好的使用场景，让我们看一些工作故事及其相应用户故事的示例。
提交订单时...
让我们从这个工作故事开始：
工作故事：
当提交订单后，我希望看到一条警告消息，以便避免重复提交订单。
此故事描述了大多数电子商务网站上出现的行为，警告用户不要重复提交订单。
等效的用户故事为：
用户故事：
作为客户，我希望显示一条消息，告诉我不要再次提交订单，这样我就不会重复下订单。
在这种情况下，工作故事比较出色，有两个原因。首先，这个故事适用于在网站上购物的每个人。因此，知道执行此操作的人是客户并不重要。（实际上，称此人为客户（customer）可能会产生误导，因为在下单之前，该人可能不是客户。）
其次，工作故事更好的原因是它提供了有关何时发生该故事的上下文。正如工作故事告诉我们的那样，这种情况是在“订单已经提交后”发生的。仔细查看用户故事，你会发现它永远不会告诉我们何时显示此消息。团队可以通过在FAQ页面上添加一个条目来实现该用户故事，警告用户不要重复提交订单，但这肯定不是PO想要的。
订单已经提交后...
接下来，让我们看一个有关通过美国邮政编码搜索地址的工作故事。
工作故事：
当按美国邮政编码搜索时，我希望输入5或9位数字的邮政编码，这样我就不会浪费时间搜索明显无效的邮政编码。
这个故事描述的是确保用户在允许搜索之前输入合适的邮政编码信息，美国邮政编码是5位或9位数字，这个故事明确说明应该避免输入两个字母也可以点击“搜索”。
等效的用户故事为：
用户故事：
作为一个用户，我希望被要求输入5或9位邮政编码，这样我就不会浪费时间搜索明显无效的邮政编码。
这两个故事强调了用户故事和工作故事之间的区别在于模板的第一部分：When…和As…子句不同。在此示例中，每个故事的其余部分在用户故事和工作故事格式上都是相同的。
与第一个示例一样，这里工作故事会更好，因为它为故事提供了更多的上下文。在这种情
