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

Question

我们刚刚开始从瀑布走向敏捷。关于我们新流程的少数投诉之一是我们的迭代计划会议花费的时间太长，主要是因为我们在会议中编写了故事卡，这就是我对流程的描述。

一个建议是我们在会议开始前写故事卡，并要求每个人在他们来到会议之前审查它们作为潜在的节省时间。

在会议期间处理故事是否有利，而不是提前写故事卡并要求人们提前审核，可能会节省每个人一些时间？

Answer 1

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

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

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

一旦完成，就会有一个随后的Sprint计划会议，项目团队会在sprint中挑选用户故事（挑选出足够的用户故事，我们认为这些故事可以根据我们建立的速度进行衡量）。

我确信其他人会采取不同的方式，关键是找到适合您和您的团队的事情。

Answer 2

  

这个过程是如何描述给我的

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

也就是说，根据我的个人经验，产品负责人向团队提供的用户故事越早越好。 Sprint Planning可能会在故事估计得到改进并且解决的细节很少的情况下进行，但如果团队至少做了一些探索和评估并且没有完全无知地参加会议，那么通常会更好。

Answer 3

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

但故事卡的讨论至关重要， 需要花费大量时间。虽然看起来很多时候可以更好地花在开发上，但事实是，如果没有讨论，开发很容易走向错误的方向。要求人们在会议之前检查卡片通常不起作用 - 如果他们不想在会议期间花时间讨论卡片，他们可能不会在自己的时间查看卡片。

我的建议：让两个人在会议开始之前共同编写用户故事，但使用会议来审核和讨论每张卡片。