虽然软件开发项目失败的原因是方方面面的，但是软件需求确实被识别为最常见的痛苦根源。
敏捷开发近些年十分流行，因为它为软件开发指引了一个方向。而用户故事是敏捷实践中一个十分重要的环节。它能帮助我们高效地收集客户真正的需求。软件开发都起始于需求收集与分析。如果一开始需求都弄错了，软件的成功也就无从谈起。同时，用户故事带来了一个十分重要的作用，即高效沟通，不论是开发团队与客户的沟通，还是团队内部成员之间的沟通。沟通使客户和团队成员都朝同一个方向前进，这意味着更少的错误，更少的浪费、风险和成本。
让我们了解写好故事所需的 5 个要素，scrum 风格。
1. 吸引读者的引人入胜的标题
这个故事需要一个准确，快速地领悟标题上面的重要信息，它应该简短突出重点， 吸引用户的眼球 。
2. 一个有待解决的冲突/问题
没有一点戏剧性的好故事是什么？故事描述通过清楚地呈现要解决的冲突/问题来奠定基础。写得很好的描述将回答故事的人物、内容和原因。
谁：客户/最终用户
什么：目标/功能
为什么：收益/商业价值。
通常，使用一个通用模板：作为（用户类型/角色），我想要（目标/功能）以便（收益/商业价值），有时上面还附着
另一张卡片或背面写着验收条件。在做计划和开发的时候，
团队可以拿着这个用户故事讨论故事细节，故事如何才算完成，
，尤其是写在书面上的时候，对于表达像软件这么复杂的需求是比较有限的。由于它们可能被误解，所以需要与开发人员、客户和用户频繁沟通。:用户故事提供了一个方法，让我们可以写下我们不会遗忘且我们可以估算和计划的，同时还鼓励沟通。
3. 增加情节的重要背景信息
一个好的故事总是包含重要的背景信息，为情节增添色彩。在 Scrum 故事写作中，我们可以将这些背景信息视为史诗，故事的母体太大、复杂、未知或风险太大，团队无法同意一次性完成。
4. 生动的细节描绘出准确的画面
估计故事的大小是好的 Scrum 故事写作的关键。正如我们之前所说，调整故事大小的目标不是建立对未来的万无一失的预测。相反，它是通过协作和信息来明确 什么 产品所有者 想要 。为此，以称为故事点的相对努力为单位完成故事的估计。这些故事点是生动的细节，可以最准确地描绘出项目的规模或努力程度。
5. 冲突/问题的解决方案/解决方案
在 Scrum 框架中 ，令人满意的“结束”采用 DoD 的形式，或完成的定义，必须满足的标准才能考虑故事“完成”。
另外软件需求是一个沟通问题。需要新软件的人(使用或销售软件的人)必须与开发新软件的人进行交流。一个项目的成功，依赖于很多不同的信息,这些信息来自各有不同人员:一方是客户和用户，有时还有分析人员、领域专家和其他从业务或组织视角来视软件的人;另一方是技术团队。一旦任何一方在沟通中把持绝对地位，项目就会遭受损失。如果业务方把持绝对位，他们就会关注软件功能和交付日期，却很少关注开发人员是否能够同时满足这两目标，或者开发人员是否确切地了解需求。如果开发人员把持绝对地位，技术术语就代替业务语言，从而导致开发人员无法倾听业务方的实际需求。
