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