用户故事大小/范围

Question

在做敏捷时，定义用户故事范围的具体标准是什么？在定义范围时，我应该考虑哪些因素？您是否为此目的使用了任何特定的公式？

Answer 1

极端编程中的“用户故事”应该是最小的商业价值单位。

一些方便的规则建议：

• 用户故事只能由业务直接编写。我们希望他们参与并感受到真正的主人翁意识。
• 所有的故事都应该附加某种商业价值 - 甚至像“让上市页面快速返回”这样的技术故事 - 需要某种商业价值，例如“为了满足我们需要返回的圣诞节订单的热潮2500个订单的上市页面不到3秒钟“。
• 我经常使用的模板（以及Rachel Davies使用过的人）

“作为利益相关方名称我想操作说明，以便业务原因 - 为什么”

• 每个用户故事都应该进行某种验收测试。当您编写故事时，您应该考虑完成的标准，但是您可以将验收测试详细信息计算为安排故事的迭代的一部分 - 只需确保首先执行此操作。 （将验收测试留到最后，然后发现实施不太正确是一个常见的错误......）
• FIT，Fitnesse，JBehave，Cucumber等技术是以客户或领域专家更容易理解的形式编写用户故事可执行验收测试的有用方法。
• 使用真实的物理索引卡，极端编程确实可以更好地工作。很容易陷入复杂的电子系统，成为它自己的子项目。如果你真的需要一个电子表格，那就让某人输入已完成的故事列表，不完整的故事而不是作为迭代摘要结束的故事。
• 用户故事是“会话令牌”。用户故事应简洁和最小化。不要将它们视为“规范” - 只是提醒我们需要做什么。 （这就是为什么他们选择在索引卡上写它们 - 你只能把它们放在一张索引卡上。）
• 如果您无法将所有文本都放在用户故事卡上 - 您可能需要拆分故事，或以某种方式简化它
• 有些人实际上禁止将网址或跟踪ID写入错误数据库或规范跟踪系统，因为这可以成为回到瀑布思考的途径 - 即编写无所不包的需求文档。
• 不允许任何人将文件或文件附在故事卡上。同样，我们不想鼓励人们编写规范 - 更好地与客户交谈并使用基于代码的验收测试。
• 对用户故事中的“和”，“也”以及“除了”以外的词语进行处理。很容易打破将每个故事保持在尽可能小的商业价值单位的纪律，并且需要保持警惕 - 特别是在压力下需要更多地适应每次迭代。
• 您应该始终能够在一次迭代中完成一个故事。这个故事要么太大，要么没有正确估计，或者如果它不适合一次迭代就会出现其他类型的问题。

Answer 2

  

在做敏捷时，定义用户故事范围的具体标准是什么？在定义范围时，我应该考虑哪些因素？您是否有任何特定的配方用于此目的？

嗯，基本规则是故事应该足够小（在故事点中）以适应迭代。实际上，对我来说，一个故事不应该超过团队速度的一半（每次迭代达到的点数）。在上面，你在迭代中冒了很多风险，你不想这样做。在这种情况下，将您的大故事分成较小的故事以减少不确定性。

那就是说，您的产品待办事项是否需要仅包含“小”的用户故事？我不这么认为。我甚至认为这将是一件坏事。通过拆分不会实现的故事，假设3个下一个迭代，分成小的，你冒险必须重新编写它们（这是浪费），然后将它们包含在迭代中。对于在3或6个月之前不会实施的故事，这样做有什么意义？相反，要及时做到这一点。换句话说，你的积压应该有一个“冰山结构”，顶层是细粒度的故事，“发布级”的更大的故事，下一个版本的更大，如下图所示（Boris Gloger的信用）：

alt text http://img507.imageshack.us/img507/5307/productbacklogiceberg.png

然后，在每次迭代期间（即在下一次迭代之前），花一些时间将大多数重要故事分成较小的故事，为下一次迭代规划做好准备。这是人们称之为product backlog grooming的内容。

关于粒度，Agile使用以下术语[Cohn2004]：

• 用户素材是从用户角度讲述所需功能的说明
• 主题是相关用户素材的集合
• Epic 是一个大型用户故事

但是对我而言，主题，史诗并不意味着大小...主题不一定比Epics更大或更小。他们只是标签。

Answer 3

由于这里的所有答案都有一些有用的评论，我决定总结一下并添加一些我自己的想法。

首先，有几个约束会影响用户故事的范围：

1. 每次冲刺后必须至少提供一些商业价值。
2. 要真正证明价值已经实现，每个故事都必须如此  伴随着已完成的定义，这意味着必须有一些  证明该功能正在运行的方式，更具技术性  术语转化为每个故事的验收测试。
3. 由于始终存在无法提供所有sprint backlog项目的风险  在sprint之后，每个人都必须一些商业价值 本身，所以至少  一些商业价值将会实现。

根据这些限制，我们可以推断出一些规则：

1. 在故事定义阶段确保产品所有者参与非常紧密，  因为他决定是否具有任何商业价值  给他。但是，由于必须至少提供一些内容，因此请确保在故事定义阶段与PO合作，以便故事合理  尺寸，至少其中一些确实将按时交付。
2. 预先为每个故事编写验收测试（在sprint计划期间）  相）。

3. 确保在最后交付至少一些商业价值  sprint，确保sprint backlog中的故事数量  与团队规模成正比。

   sprint积压中的项目数量应该与团队规模成正比是什么意思？以下是一些可以适用于一些非常小的团队（2-10人）的想法：

   如果团队中有少数人（比如两个最极端的模型情况）并且sprint backlog包含  只有两个项目，你很有可能没有完成任何一项。  换句话说，这里不接受一个冲刺的故事大小。  只有几个具有高故事点值的故事意味着如果你错过了  只有其中的一两个，你可能会错过应该交付的很大一部分。  除此之外，如果你的故事不够精细  你将在下一个sprint计划会议中遇到麻烦，因为你没有空间来进行操作  （如果它们太大，就很难在sprint backlog中添加或删除它。）  我认为动机心理学也可以在这里发挥作用。战斗很小  更容易获胜，失去他们不会伤害那么多。

   为了避免上述问题，你应该决定你要提出的一些严格的故事  进入每个sprint积压，这意味着必须有一些明确的最大尺寸  每个故事。

   我的经验法则可能就是这样 - 失去一个故事绝对不应该意味着失去整个冲刺。它也许并不意味着减少50％的交付量。我认为失去一个故事不应该伤害很多。在考虑特定故事的范围时，人们应该提出这样的问题：如果我们在这个冲刺期间丢失了这一个故事，那会非常痛苦吗？或者，是否会迅速拖累整个团队的士气？如果答案是肯定的，那么这个故事对于团队规模来说可能太大了。

   如果你在冲刺积压中说100分并在冲刺期间失去20分意味着灾难，你可能不应该在你的冲刺积压中有超过15分的故事。

   我试图提出一些更精确的公式，但最后我决定每次迭代6-10个故事为我们的小团队，最大规模为1.5天（正如其他人在这里提出的那样） ），因为它似乎与我在这里所说的一致。

Answer 4

以下是一些简单的提示，可能对您有所帮助 -

1. 沿着故事支持的数据边界拆分大型故事。

2. 根据故事中的操作拆分大型故事。

3. 将大型故事拆分为单独的CRUD [创建，读取，更新，删除]操作。

4. 考虑删除横切关注点（例如安全性，日志记录，错误处理等）并创建两个版本的故事：一个支持和一个不支持交叉问题。

5. 考虑通过将功能性和非功能性[性能，稳定性，可伸缩性等]方面分离为不同的故事来分割大型故事。

6. 如果较小的故事具有不同的优先级，则将大故事分成较小的故事。

这些观点来自James Shore的敏捷开发艺术。有关详细信息，请阅读 - The Art of Agile Development: Storie

Answer 5

这是一个很好的问题。做得好的关键是PO和团队之间的良好合作。 PO拥有积压，是唯一一个保持更新的人。但是团队必须提供他/她的反馈才能有效地构建它。我发现，如果PO和tam没有合作，需要一段时间才能适应团队在给定时间内完成的“大小”故事，因此首先需要更多的协作。

我认为理想的故事需要2天或更短的团队时间。显然，根据你的团队规模和能力，或多或少复杂的故事可以在那段时间内完成。我目前的团队很小（3开发1测试），所以我们发现任何得分为8或更高的东西都是可疑的，需要拆分，因为它可能需要2天以上。

PO不知道也无法对故事进行评分，所以他只有直觉感觉能帮助他写故事。所以很多时候团队必须帮助他重新编写更小的东西。这是在sprint计划会议之前完成的。 PO会随着时间的推移而变得更好，就像团队估计大小一样，并且能够回顾积压，看看新的东西是什么样的东西，这将有助于他正确地调整大小。在团队帮助他做几次之后，他最终会自动将“保存”故事分解为“删除”，“添加新”和“编辑现有”故事。

无论如何，每个故事的回答都是2天或更短 要考虑的因素是团队规模，团队能力，产品类型 公式是1-x故事点 - ＆gt;好故事; ＆gt; x故事点 - ＆gt;太史诗了。其中x是你团队的2天门槛。

Answer 6

故事应为客户带来价值，并具有验收标准，以便很容易知道故事是否完整。

此外，尺寸重要，团队将能够在迭代中完成5到10个故事。

如有必要，用户素材可以是split或分组。

Answer 7

至于找出你需要包含哪些细节，与团队交流 - 如果你给他们一个用户故事的概述，他们会问你可以添加到特定要求的问题用于完成用户故事。在我的办公室，我们每周都会举行会议（除了sprint计划），我们需要30-60分钟的时间来查看与PM一起的积压故事，让团队有机会澄清任何歧义和大小。

我们会看到2-3个值得工作的短跑，这让PM有足够的时间来重新制定或分解故事，如果它们在被介绍给团队时声音很大。