我正在参与一个大型项目的开发。在编写代码时，我们会不断地召开规模评估会议，所有开发人员都要和团队一起讨论用户故事的规模。
有些人质疑Scrum的这个过程需要太长的时间，导致开发时间被浪费了。
我的问题是，平均需要多长时间来评估一个用户故事的规模？是否有任何技巧可以使这些评估会议更快速？
6个回答
4
- 只关注下一个迭代中的用户故事
- 如果您需要未来故事的一些估算，请仅使用T恤尺码。
- 设定时间限制进行估算，并确保足够的前期分析（但要小心，不要进行大量的前期分析，只需了解所涉及的用户故事即可）
- 使用规划扑克牌
- 拆分故事，如果拆分过程太长，请再次拆分，但请尽量保持功能的垂直切片，如果难以理解，请重构您的故事
- 让有经验的人来主持计划会议
您的两周迭代计划会议不应超过1小时，但当您开始使用Scrum时，往往需要1天。只需练习，不要忽略分析。
规划会议毕竟是一个主要的学习机会，因此如果您专注于理解需要完成的工作（并且顺带了解需要多长时间），您并没有浪费时间。- mfloryan
1
1我喜欢这个T恤尺码的想法...很聪明！ - Ryan Tenney
2
Scrum是一种非常以客户为导向的方法论。你将把它交付给谁？他们的最高优先事项是什么？此外，对于那些不太可能在短时间内完成的项目，您无需为其编写用户故事。当然，它们需要在某个时候完成，但现在您没有时间。
你的Sprint有多长？两周吗？花两个小时与开发人员一起查看Sprint的任务。确保每个人都有60-70个小时的工作量（永远不要给80个小时，否则您会失败...），然后Scrum Master可以专注于用户故事。如果您有如此庞大的待办事项清单，则可能需要一个产品经理，其工作是与客户进行接口交互并管理待办事项清单。
简而言之：
1. 制作一个后备待办事项清单，并将那些您不打算立即处理的事项放入其中。等到客户提出这些事项时再处理。
2. 确保开发人员在Sprint期间有任务可做。现在专注于这个Sprint，等这个Sprint真正开始后再考虑下一个Sprint。
3. 用户故事很重要，毫无疑问。但是所有开发人员是否都需要一起处理每个故事？故事不应该是开发人员的工作。它们应该是经理/客户的工作。如果开发人员必须处理它们，要么放弃用户故事（如果您可以从开发人员已有的内容中生成用户故事，那么它就不是很有用，因为它不是“用户”故事！），要么让开发人员快速编写并获得Scrum Master批准。
编辑：我以为你在编写用户故事，而不是在进行大小估算。我的错！但是，第1点和第2点仍然适用。
你的Sprint有多长？两周吗？花两个小时与开发人员一起查看Sprint的任务。确保每个人都有60-70个小时的工作量（永远不要给80个小时，否则您会失败...），然后Scrum Master可以专注于用户故事。如果您有如此庞大的待办事项清单，则可能需要一个产品经理，其工作是与客户进行接口交互并管理待办事项清单。
简而言之：
1. 制作一个后备待办事项清单，并将那些您不打算立即处理的事项放入其中。等到客户提出这些事项时再处理。
2. 确保开发人员在Sprint期间有任务可做。现在专注于这个Sprint，等这个Sprint真正开始后再考虑下一个Sprint。
3. 用户故事很重要，毫无疑问。但是所有开发人员是否都需要一起处理每个故事？故事不应该是开发人员的工作。它们应该是经理/客户的工作。如果开发人员必须处理它们，要么放弃用户故事（如果您可以从开发人员已有的内容中生成用户故事，那么它就不是很有用，因为它不是“用户”故事！），要么让开发人员快速编写并获得Scrum Master批准。
编辑：我以为你在编写用户故事，而不是在进行大小估算。我的错！但是，第1点和第2点仍然适用。
- corsiKa
2
我们在约30秒到一分钟内为用户故事确定大小。
我们讨论用户想要什么的基础，很少花时间讨论如何实现。如果你深入探讨了如何实现，那么你就是在将故事分解成任务，这是不同的活动。
关于故事“如何”方面最多讨论的内容是任何风险（例如使用团队中没有经验的技术）。
这是确保确定大小不会花费太长时间的关键。你不是来设计整个故事的，只是确定其大小。了解需要完成的基本工作，然后就此结束。除非有显著的时间差异，否则绝对不要争论如何完成故事。
简短讨论后，每个人都选择一个数字（可以使用故事点卡或心中默念）。然后展示数字并讨论任何差异。
经过短暂的讨论后，需要达成共识。
另一个关键点是不要为当前或即将推出的史诗/版本之外的故事确定大小。Scrum变化太快，浪费时间确定可能被淘汰或拆分的故事。
我们讨论用户想要什么的基础，很少花时间讨论如何实现。如果你深入探讨了如何实现，那么你就是在将故事分解成任务，这是不同的活动。
关于故事“如何”方面最多讨论的内容是任何风险（例如使用团队中没有经验的技术）。
这是确保确定大小不会花费太长时间的关键。你不是来设计整个故事的，只是确定其大小。了解需要完成的基本工作，然后就此结束。除非有显著的时间差异，否则绝对不要争论如何完成故事。
简短讨论后，每个人都选择一个数字（可以使用故事点卡或心中默念）。然后展示数字并讨论任何差异。
经过短暂的讨论后，需要达成共识。
另一个关键点是不要为当前或即将推出的史诗/版本之外的故事确定大小。Scrum变化太快，浪费时间确定可能被淘汰或拆分的故事。
- Vaccano
4
我会小心不要将待办事项进一步缩小。这对于产品负责人在优先安排工作时了解故事有多昂贵非常有帮助。此外，如果您没有估算待办事项，产品负责人无法根据速度计划/预测未来特性的大致发布日期。 - DancesWithBamboo
1理解故事 - 估算故事规模 - 讨论差异 - 调整大小以达成共识 -------------- 这个过程如何在30秒内完成？通常情况下，我们会根据故事的复杂性花费2-10分钟来完成每个故事。 - Baiyan Huang
既然我们都已经在这个项目上工作了一段时间，通常我们都知道故事的基本内容（所以理解故事并不难。只需要阅读它，大约需要15-30秒）。然后我们都选择一个数字并展示出来。经常数字是相同的。如果是，那么我们就完成了。如果不是，好吧，我说过30秒到1分钟。这就是额外的时间。与其他人最不同的人简要地说明他们为什么投票。我们通常很快达成共识。 - Vaccano
如果你做这个花费的时间太长了，那么我会说你的故事太大了或者你在设计时应该进行大小估算（尽管2-4分钟并不算太长）。 - Vaccano
1
这是我所做的：
将您的规划扑克会议限制在5名开发人员内。尽量选择代表性强的人员（有经验的、没有经验的、话多的、害羞的等）。经常轮换（不要每次都选同样的人）。
如果描述用户故事需要太长时间，那么很可能这个用户故事写得不好。改进您的用户故事。编写良好的用户故事非常重要。一个典型的用户故事应该在3分钟内完成大小估算，并通过两张卡片。有时速度会更快，有时会更慢。
如果您有太大（工作量）的用户故事，请将其拆分。如果您的估算超过13个“工作日”，则您的用户故事存在问题。
如果您有太多的用户故事，请在估算会议之前根据业务价值进行预先优先排序。稍后您可以调整优先级。我通常会因此将项目分成组件。如果仍然有太多的用户故事，您可能需要人手不足，需要创建第二个团队。
您的团队会随着时间的推移而更快地进行估算
为您的规划扑克会议设置时间限制！如果时间过长，参与的开发人员会感到无聊，这会使会议变得更长...文献告诉您将其时间限制为4小时。根据我的经验和观察，在欧洲团队中至少是远远太多了。尝试2x 1小时并休息一下。
如果所有这些都不起作用，请雇用一位有经验的Scrum Master（在类似项目规模的情况下担任全职且活跃的Scrum Master超过3年）。如果此后仍然不起作用，请停止使用Scrum。Scrum在某些公司，特别是在公共部门中可能非常具有破坏性。
- user333306
2
将开发人员轮流参加规划扑克会议的想法让我感到害怕。如果团队不是相对稳定的，那么如何建立可信的速度？ - Mark Peters
如果总是同一批开发人员进行估算，那么如何建立可信的估算？ - user333306
0
1分钟；如果故事太大，超过这个时间就太长了。如果每个故事都有很多讨论，那么SM需要帮助PO编写更小、更好、更简洁的故事。
在冲刺计划会议之前，PO想要处理的史诗应该被分解成小块。我猜你没有好的质量故事来评估大小，你的PO可能需要帮助你做到这一点。
我不确定你所说的“无尽的大小估算会议”是什么意思。你的2周冲刺计划会议应该限时<=4小时。为什么会无尽呢？
- DancesWithBamboo
3
如果你将大故事分解成更小的故事，那么你就有了更多的故事，这意味着估算故事所花费的总时间不会改变。 - Baiyan Huang
我不认为这是真的。就像8或13号故事的建造更加复杂，有更多未知因素；估算它们有更多未知因素，因此会导致更多的讨论。3或5这样的小故事相当简单明了，减少了团队讨论的需求，也减少了大小分歧。 - DancesWithBamboo
我同意DancesWithBamboo的观点。相较于一个大故事，小故事更加准确。而且，拆分成小故事有助于进行相对估算比较。 - Adam
0
Scrum不允许无限期地进行。Scrum为每个必须进行的会议设置了时间框。
- 对于一个月的Sprint，Sprint计划会议应该是8小时（或者按比例缩短Sprint持续时间）；
- Sprint永远不能超过一个月，但可以是两周；
- 每日Scrum时间框为15分钟，如果不需要全部时间，则始终可以缩短；
- 对于一个月的Sprint，Sprint回顾会议为4小时，对于较短的Sprint则更少；
- 对于较短的Sprint，Sprint回顾会议为2小时或更短；
在我看来，无限期地进行没有意义。Scrum更喜欢尊重时间框架。如果还没有决定从哪个最关键的产品待办事项开始，团队就选择最高的项目（团队认为可以在一个Sprint中完成的项目），并开始执行。
花费很长时间毫无意义，而且有重复自己的风险，这只会导致Scrum团队成员之间越来越混乱。请记住，管理层在Scrum中没有角色，所以他们是“鸡”，他们没有发言权，即使是CEO也是如此！如果CEO有话要说，他必须告诉产品负责人，而产品负责人的职责是看看如何从正在进行的工作中获得最好的价值回报。他是唯一被允许打断Sprint的人，但通常不需要打断因为Sprint的时间很短。
- Will Marcouiller
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接