10

我在一个巨大的项目上工作。在我们进行编程时，我们最终会召开无休止的积压调整会议，所有开发人员都会与团队坐下来调整用户故事的大小。

Scrum 怀疑者说这个过程花费的时间太长，而且开发时间被浪费了。

我的问题是平均需要多长时间才能确定用户故事的大小？有没有人有任何提示可以让这些尺寸调整过程更快？

4

6 回答 6

4
  • 只关注下一个 sprint 的用户故事
  • 如果您需要对未来的故事进行一些估算，请仅使用 T 恤尺码
  • 为您的估计会话设置时间框并确保预先完成了足够的分析（但要小心，不要预先进行大分析，仅足以理解相关的用户故事）
  • 使用计划扑克
  • 分解故事，如果时间太长，再次分解，但尽量保持垂直的功能部分，如果故事难以理解，请重构你的故事
  • 让有经验的人协助计划会议

为期两周的 sprint 计划会议不应超过1 小时，但当您开始使用 Scrum 时，通常需要1 天。只是练习，不要遗漏分析。

毕竟，计划会议主要是一个学习机会，所以如果您专注于了解需要完成的工作（以及作为副产品需要多长时间），您并没有真正浪费时间。

于 2010-06-28T15:03:10.377 回答
2

Scrum 是一种非常基于客户的方法。你会把它交给谁？他们的最高优先级是什么？此外，您不需要为短期内不太可能完成的项目制作用户故事。当然他们需要一些时间来完成，但你现在没有时间。

你的冲刺有多长时间。两周？花两个小时与您的开发人员一起研究 sprint 的任务。确保每个人都有 60 到 70 小时的工作时间（永远不要给 80 小时，否则你只会炸毁……），然后 scrum master 可以专注于用户故事。如果你有这么大的积压工作，你可能需要一个产品经理，他的工作是与客户沟通并管理积压工作。

简而言之

  1. 做一个back-back-log，把你不会很快做的事情放进去。当客户提出他们时处理他们。
  2. 确保开发人员在 sprint 中完成任务。现在专注于这个 sprint，一旦这个 sprint 真正开始，就关注下一个 sprint。
  3. 毫无疑问，用户故事很重要。但是所有开发人员都需要在每个故事上一起工作吗？故事不应该是开发人员的工作。他们应该是经理/客户的工作。如果开发人员必须这样做，要么放弃用户故事（如果您可以从开发人员已经可用的内容中生成用户故事，那么它不是很有用，因为它不是“用户”故事！！！）或者拥有开发人员快速编写一个并获得 Scrum Master 的批准。

编辑：我以为你在写用户故事，而不是大小。我的错！但是，第 1 点和第 2 点仍然适用。

于 2010-06-10T15:19:05.060 回答
2

我们在大约 30 秒到 1 分钟内调整用户故事的大小。

我们讨论用户想要什么的基础知识。很少有时间花在如何完成上。如果你对它是如何完成的太过分了，那么你就是在为故事分配任务，这是一个不同的活动。

关于故事的“如何”最应该讨论的是任何风险（例如使用团队中没有人使用过的技术的故事）。

这是确定尺寸不会永远占用的关键。你不是来设计整个故事的。只是为了调整它的大小。对需要做的事情有一个基本的了解，然后把它留在那里。除非不同的方法存在显着的时间差异，否则不要最终争论故事将如何完成。

经过简短的讨论后，每个人都选择了一个数字（使用故事点卡或只是在他们的脑海中）。然后，您显示数字并讨论任何差异。

经过短暂的讨论后，需要达成共识。

另一个关键是不要调整不在当前或即将发布的史诗/版本中的故事。Scrum 变化太快，以至于无法确定可能被消除或分解的故事的大小。

于 2010-06-10T15:20:38.277 回答
1

这就是我所做的：

  • 将您的计划扑克会议限制为 5 位开发人员。尽量选择有代表性的（有经验、没经验、大嘴巴、害羞等）。经常轮换它们（不要每次都选择相同的）。

  • 如果描述您的用户故事的时间太长，则可能意味着用户故事写得不好。改进您的用户故事。编写好的用户故事非常重要。一个典型的用户故事应该在不到 3 分钟的时间内完成，并且通过两张卡片。有时会快很多，有时会慢很多。

  • 如果您有太大的用户故事（工作量），请将它们拆分。如果您的估算时间超过 13 个“工作日”，那么您的用户故事就是问题所在。

  • 如果您的用户故事真的太多，请在基于业务价值的评估会话之前进行预先确定优先级。稍后您将调整优先级。因此，我通常将项目拆分为组件。如果用户故事仍然太多，您可能需要人手不足，您需要创建第二个团队。

  • 您的团队将随着时间的推移更快地进行估算

  • Timebox 您的计划扑克会议！如果持续时间过长，参与的开发人员会感到厌烦，这会使会议变得更长……文献告诉您将时间限制为 4 小时。恕我直言，根据我在我的 scrum 团队中观察到的情况，这太过分了，至少在欧洲团队中是这样。尝试 2x 1h 暂停。

  • 如果所有这些都不起作用，请聘请一位经验丰富的 Scrum Master（3 年以上的全职工作和积极的 Scrum Mastering，项目规模与您的相似）。如果在那之后它不起作用，请停止使用 Scrum。Scrum 在某些公司中可能具有很大的破坏性，尤其是在公共部门。

于 2010-06-28T14:55:19.640 回答
0

1分钟; 不仅如此，你的故事也太大了。如果每个故事都有很多讨论，那么您的 SM 需要帮助您的 PO 编写更小/更好/简洁的故事。

在 sprint 计划会议之前，PO 想要处理的史诗应该被分解成小块。我的猜测是你没有高质量的故事来调整大小，你的 PO 可能需要帮助才能让这部分适合你。

我不确定您所说的“无休止的尺寸调整会议”是什么意思。为期 2 周的 sprint 的 sprint 计划会议应该安排在 <=4 小时的时间。为什么是无穷无尽的？

于 2010-06-11T15:57:24.780 回答
0

Scrum 不允许永远占用。Scrum 为它必须举行的每次会议设置了时间框。

  1. 每月 Sprint 的 Sprint 计划会议应为 8 小时（或与 Sprint 持续时间成比例更少；
  2. Sprint 不能超过一个月，但可以是两周；
  3. Daily Scrum 时间框是 15 分钟，如果不需要一直都可以，可以更短；
  4. 每月 Sprint 的 Sprint 审查会议为 4 小时，较短的 Sprint 时间更少；
  5. Sprint 回顾会议为 2 小时或更短，Sprint 更短；

在我看来，它并没有使用永远的目的。Scrum 更喜欢尊重时间框架。如果尚未就最关键的产品待办事项项目一开始做出决定，那么团队将选择最重要的项目（团队认为它可以在一个 Sprint 中交付的数量），然后继续执行。

冒着重复自己的风险，永远坚持下去没有任何意义，因为这只会导致 Scrum 团队成员之间越来越混乱。请记住，管理层在 Scrum 中没有任何作用，所以他们是“鸡”，他们没有发言权，甚至连 CEO 也没有！如果 CEO 有话要说，他必须告诉产品负责人，而产品负责人有责任看看他如何从所做的事情中获得最佳的价值回报。而且他是唯一被允许打断 Sprint 的人，由于 Sprint 所需的时间很短，这通常是不必要的。

于 2010-10-29T02:58:05.517 回答