Scrum积压大小正在耗尽

Question

我在一个庞大的项目上工作。在我们计划的过程中，我们最终会召开无休止的积压大小会议，所有开发人员都坐下来讨论团队和大小的用户故事。

Scrum怀疑者说，这个过程耗时太长，开发时间浪费了。

我的问题是，平均缩小用户故事需要多长时间？有没有人有任何提示让这些尺寸调整会更快？

Answer 1

• 仅关注下一个sprint的用户故事
• 如果您需要对未来的故事进行一些估算仅使用T恤尺寸
• 时间框您的估算会话并确保预先完成足够的分析（但要小心，不要在前面做大分析，只够了解有问题的用户故事）
• 使用planning poker
• 打破故事如果耗时太长，请再次打破它们，但尝试保留垂直切片功能，如果难以理解则重构故事
• 让某人经历促进计划会议

为期两周的sprint的计划会话不应超过 1小时，但是当你开始使用Scrum时， 1天并不罕见。只是练习，不要离开分析。

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

Answer 2

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

你的冲刺有多长。两个星期？花两个小时与开发人员一起完成sprint的任务。确保每个人都有60-70小时的工作时间（从不给80，或者你只是炸弹......）然后scrum master可以专注于用户故事。如果你的积压很大，你可能需要一个产品经理，他的工作是与客户交流并管理积压工作。

简而言之

1. 制作一个回溯记录，并把你不会在短时间内做的事情放在其中。当客户提起它们时处理它们。
2. 确保开发人员具有处理sprint的任务。这个sprint实际上已经开始，现在关注这个sprint现在和下一个sprint。
3. 毫无疑问，用户故事很重要。但是，所有开发人员是否需要在每个故事上一起工作？故事不应该是开发人员的工作。他们应该是经理/客户的工作。如果开发人员必须这样做，要么放弃用户故事（如果你可以从开发人员已经拥有的内容中生成用户故事，它不是非常有用，因为它不是“用户”故事!!!）或者有开发人员快速编写一个并由scrum master批准。

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

Answer 3

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

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

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

这是衡量不要永远消失的关键。你不是在那里设计整个故事。只是为了它的大小。了解需要完成的工作并将其留在那里。除非在不同的方法中存在显着的时差，否则最终不会争论故事将如何完成。

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

经过短时间的讨论，需要达成共识。

另一个关键的事情是不要调整当前或即将发布的史诗/发行版中的故事。 Scrum的变化太快，腰围时间可以消除或分解故事。

Answer 4

这就是我的所作所为：

• 将您的计划扑克课程限制为5名开发人员。尝试挑选有代表性的人（经验丰富，没有经验，大嘴巴，害羞等）。经常旋转它们（每次都不要选择相同的颜色）。

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

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

• 如果您有太多用户故事，请在估算会话之前根据业务价值进行预先优先排序。您将在稍后调整优先级。我通常将项目拆分为组件。如果用户故事仍然太多，您可能需要人手不足，而且您需要创建第二个团队。

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

• Timebox您计划的扑克课程！如果它持续太长时间，参与开发人员会感到无聊，这会使会议更长......文学告诉你将它们计时到4h。恕我直言，以及我在Scrum团队中观察到的情况，这太过分了，至少在欧洲团队中是这样。暂停尝试2x 1h。

• 如果所有这些都不起作用，请聘请经验丰富的Scrum Master（超过3年的全职和活跃的Scrum Mastering，与您的项目规模相似）。如果之后不起作用，请停止使用Scrum。某些公司的Scrum可能非常具有破坏性，特别是在公共部门。

Answer 5

1分钟;更重要的是，你的故事太大了。如果对每个故事都有很多讨论，那么你的SM需要帮助你的PO写出更小/更好/更简洁的故事。

在竞标计划会议之前，应该将PO希望工作的Epics细分为小块。我的猜测是你的大小没有高质量的故事，你的PO可能需要帮助才能让你的部分适合你。

我不确定“无休止的大小调整会议”是什么意思。您的冲刺计划会议为期2周的冲刺应该在<= 4小时的时间内进行时间框。为什么它是无止境的？

Answer 6

Scrum不允许永远占用。 Scrum为每次必须进行的会议都有时间框。

1. Sprint计划会议每月Sprint应该是8小时（或者与Sprint持续时间成比例地减少;
2. Sprint永远不会超过一个月，但可能会持续两周;
3. 每日Scrum时间框为15分钟，如果不需要所有时间，总是可以减少;
4. Sprint评审会议每月Sprint为4小时，较短的Sprint为
5. Sprint回顾会议为2小时或更短时间，以缩短Sprint;

在我看来，它并没有使用目的永远。 Scrum更喜欢尊重时间表。如果没有做出关于什么是最重要的产品Backlog项目的决定，那么团队然后选择最重要的项目（尽管团队认为它可以在一个Sprint中提供），并继续使用它。

没有任何目的可以永远承担，重复自己的风险，因为这只会导致Scrum团队成员之间越来越混乱。请记住，管理层在Scrum中没有任何作用，所以他们是“鸡”，他们没有发言权，甚至是CEO！如果首席执行官有话要说，他必须告诉产品负责人，产品负责人有责任了解他如何从正在完成的工作中获得最佳价值回报。并且他是唯一被允许中断Sprint的人，由于Sprint短时间内通常不需要。