产品Backlog订购最佳实践或建议

Question

假设产品积压说... 200故事。在订购积压时，您是否订购了所有200个故事，或者只是选择您将在该冲刺期间处理的下一个X号码？

Answer 1

产品待办事项就像是将需求传达给团队的管道。在管道的一端，要求非常原始。在另一端，他们​​已准备好接受工作。

积压顶部的项目通常状况良好。产品负责人和团队已经查看过它们，讨论过它们，优先考虑它们，甚至有时估计它们。

短暂冲刺的项目仍处于良好状态。但他们可能尚未准备好进入冲刺阶段。需要进一步细化。

超过2个冲刺的物品可能非常粗糙。他们甚至可能没有被分解成故事。可能存在一些优先级，但它非常笼统，不太可能被详细考虑。

我们这样做的原因是：

• 在与敏捷合作时，我们预计会发生变化。因此，如果事情可能会发生变化，那么未来几周/几个月的详细优先级要求可能会浪费，
• 我们进一步开展工作，更有可能要求本身可能会发生变化。为了解决这个问题，我们保留了将来非常粗糙的要求。这些更粗糙的要求往往比详细要求具有更长的保质期。

因此，我对你的问题的回答是，在接下来的1-2个冲刺中，优先考虑并保持良好状态的故事数量。但是你得到的越远，重要性就越低。

Answer 2

这是一个＆＃34;技巧＆＃34;问题，因为如果你没有订购或考虑所有的故事，你如何能够为下一个冲刺带来故事。我们做了什么 - 我们首先定义下一个sprint目标，并尝试找到主要实现此目标的故事集。您之前在故事中设置的标签也可能会有所帮助。然后你只需使用适当标签的套装，并考虑下一个冲刺最重要的东西。

Answer 3

我们通过EPIC（主要功能/主要功能）对功能进行分组，以便快速了解主题。

我们将优先考虑： 1）错误，生产错误，强制迁移 2）新功能（EPIC） 3）技术更新

如果在3个月内没有使用EPIC（任务组，用例），我们将其放入我们称之为Iceberg Backlog（这是一个远远的积压日志）中，我们每年都会审查它。

这样做过程非常快速且易于理解。