agile - 迭代计划之前或期间的用户故事

Question

我们才刚刚开始从瀑布式转向敏捷。关于我们的新流程的少数抱怨之一是我们的迭代计划会议花费的时间太长，主要是因为我们在会议本身中编写故事卡，这就是向我描述流程的方式。

一个建议是，我们在会议之前编写故事卡，并要求每个人在参加会议之前对其进行审查，以节省潜在的时间。

在会议期间讲故事，而不是提前写故事卡片并要求人们提前回顾它们，有可能为每个人节省一些时间吗？

Answer 1

这可能不是一个理想的问题，因为没有真正确定的答案。反应可能是主观的。

根据我自己的经验，我们的团队倾向于让利益相关者和产品负责人在我们的冲刺期间以临时方式将用户故事添加到项目产品待办事项中（我们在 Web 应用程序上工作，并且在功能方面是用户驱动的 - 我们确实有路线图，但我们也适应反馈等）。

这样，当需要进行迭代计划时，我们会与利益相关者、产品负责人和项目负责人举行一次简短的产品计划会议，讨论优先级并调整我们产品待办事项上的用户故事。

完成后，项目团队将进行后续的 Sprint 计划会议，这些会议将挑选用户故事以在 sprint 中工作（挑选出足够多的用户故事，根据我们既定的速度衡量，我们认为可以实际实现）。

我相信其他人的做法不同，关键是找到适合你和你的团队的东西。

Answer 2

这就是向我描述的过程

你在你的过程中发现了一个问题（计划会议太长）并找出了它的根本原因（写故事卡）。最明智和最敏捷的做法可能是不要固守“过程是如何描述的”，而是相应地进行调整，这意味着提前创建卡片。

也就是说，根据我的个人经验，产品负责人越早向团队介绍用户故事越好。冲刺计划可能会在对故事估计进行细化并处理一些细节时进行，但如果团队至少提前进行了一些探索和估计并且不要完全无知地到达会议，那通常会更好。

Answer 3

用户故事最重要的目的之一是充当开发人员和利益相关者之间的对话开始者。根据我的经验，让一两个人审查所有现有的需求或请求并将它们转化为用户故事可以节省大量时间。

但讨论故事卡至关重要，这需要相当长的时间。尽管看起来很多时间可以更好地用于开发，但现实情况是，如果不进行讨论，开发很容易走错方向。要求人们在会议前回顾卡片通常是行不通的——如果他们不想在会议期间花时间讨论卡片，他们可能不会在自己的时间里回顾卡片。

我的建议：请两个人在会议之前一起编写用户故事，但要利用会议来审查和讨论每张卡片。