提示：本文共有 972 个字，阅读大概需要 2 分钟。
（1）故事标题
用户故事的描述在列表中进行管理时，不利于快速理解，也不能一行展示。为每个故事取个标题（名字）就很有必要，而且像禅道、TAPD软件的需求表述格式中标题也是必填项。就行邮件的主题，用户故事的标题是为了让读者能快速了解这个用户故事的要点和大致范围。怎么写好标题也是有章可循的。
常见的做法有：
用户角度的动宾短语如，创建商品，输入名称，修改头像，等等这是动作+对象形式，擅长描述从用户看到的活动或功能。
系统角度的动宾短语此处的系统是指待开发的对象。
如，toast提示网络异常，记录用户访问次数，显示搜索结果，显示倒计时。擅长描述系统要执行的反馈和操作。
主谓宾短语有时动宾短语不能推断主语时使用主谓宾短句，或者可能有可能混淆时需要明确主语，此时就需要增加动作主语，如，超级管理员重置普通管理员的口令；A系统推送批量客户和合同信息。
随着时间推移，新增的用户故事有不少是基于原有的功能来再提升修改，这时往往要在标题里加上状语来区分，比如根据客户所在城市来查询客户列表，在客户没有登记电话号码时强制客户登记号码。 状语要清晰得说明用户故事所处的情况，能够区分类似的用户故事。
差劲标题举例
1，外访业务处理
点评：处理是万金油词语，没有突出重点。
2，设计资产逾期流入流出报表。
点评：主语既不是用户，也不是待开发的系统，而是开发人员，这更像是一个任务的标题。
3，角色分配资源
点评：要做什么呢？不能快速理解故事核心。
（2）故事描述固定格式“作为……（用户角色），我想要……（完成活动），以便于……（实现价值）”的格式。故事描述一这种三段式表述，相比较于传统需求表述，体现了需求方和需求价值的重要性，也为保证了需求描述的可协商性。
（3）规则描述为了完成故事，有时需要制定故事的实现规则，涉及的名词定义等。规则描述由产品经理初步制定，在故事讨论后，进行修订确认。写作方式就是一条条穷举列出。注意这里不涉及原型页面和交互规则。
（4）验收标准可作为验收测试用例的具体例子。这也是我们常说的实例化需求，也是为了避免误读，让抽象的需求变得具体和可测试。
这一步很难，但非常重要。没有明确的验收条件，我们便不知道如何测试，业务也不知道如何验收。
通常，一个用户故事包含若干个验收条件，包括快乐路径（Happy Path）与意外场景（Exceptional Scenario）。
看到此处说明本文对你还是有帮助的，关于“用户故事3：用户故事该怎么写？”留言是大家的经验之谈相信也会对你有益，推荐继续阅读下面的相关内容，与本文相关度极高！
