我猜一个功能可能是“信用卡授权”，而用户故事可能是“为 paypal 授权信用卡”。
那么，用户故事是功能的子集吗？
【问题讨论】：
标签： agile user-stories
是的，类似于子集。这篇文章很好看：
Features vs Stories
摘录：
我今天意识到我没有 明确我心中的差异 在功能和故事之间 一个重要的区别。本质上， 特征是一组故事 相关并提供一揽子 最终用户会使用的功能 通常期望一次得到所有。 例如，内联表调整大小是 一个功能（注意：这是能力 拖动以调整表格、行和 列 – 在 Word 中尝试）。在里面 第一次通过，你可能会有一个 用于内联调整大小的单个故事 桌子，但它太大了 估计。所以你把它分解成 三层楼，调整列大小，调整大小 行并调整表格本身的大小。
【讨论】：
Diego's这个页面上的帖子，一个令人耳目一新的视角。
根据Kent Beck and Martin Fowler stories 和 features 是同义词：
用户故事是一大块 功能（有些人使用 词 feature) 对 客户。
您所说的功能通常被称为主题或史诗。主题和史诗用于将用户故事分组为更大的功能集，这些功能集本身就有意义。
从更语义化的角度来看：功能是您尝试构建的系统的一部分，用户故事是描述该部分的一种方式。
更正：
正如 Pascal 所指出的 - 我可能错过了引用中“功能”的真正含义（“功能”显然是指功能）除此之外，我仍然认为可以使用这些词（功能和用户故事）作为很多上下文中的同义词（“我正在研究这个故事”与“我正在研究这个功能”），因为正如 Pascal 所说，用户故事是一种捕捉功能的方式。这意味着这两者之间存在1：1的关系。而且，从我对语义的评论中可以看出，这就是我真正理解的方式。
【讨论】：
一点也不..
用户故事代表业务价值的一小部分。 所以很难说用户故事是功能的子集还是功能是用户故事的子集（还要记住，用户故事通常是由利益相关者编写的，他们往往不知道具体是什么他们想要... :) )
因此，如果您遵循敏捷的建议来保持故事简短，您将陷入“最佳”场景，即用户故事是功能的子集。
但是，如果您的利益相关者写长故事，每个故事都会有几个特点（如果团队和利益相关者之间有良好的沟通，这不会发生，因为团队会将故事分成小故事）
【讨论】：
功能是系统正在执行的操作。用户故事只是捕捉功能的一种方式。
【讨论】：
当我在寻找关于“针对类似需求使用多个角色”的不同想法时，我刚刚遇到了这个话题。
我认为，作为相关故事容器的功能有助于确定需求的优先级，因为利益相关者通常将他们的需求作为相关故事来讲述。在最近的一个项目中，客户告诉我如下
成员可以向管理员发送消息 管理员可以向所有成员发送消息 成员可以互相发送消息
当我看到这些要求时，我知道，我们应该实施一个系统来使人们能够发送消息，并且我们应该添加检查以允许谁做什么。
而且我知道这些要求可能还有其他一些隐含的要求，例如阅读收到的消息、整理它们、可能设置为垃圾邮件等。
所以我尝试将这些要求改写为
作为会员或管理员，我可以向其他人发送消息。 作为会员或管理员，我可以阅读发送给我的消息。
作为验收标准，我详细说明了谁可以发送给谁。
然后我将所有这些东西称为“私人消息传递”功能，这样，稍后，如果客户认为这是额外费用，他可以说“放弃私人消息传递”，我可以删除所有这些都来自积压。
【讨论】：