应该允许谁在产品积压中添加故事？

Question

什么是最佳实践，以防止积压成为一个混乱，但也保持开发人员的生产力。

我们应该允许谁在产品积压中添加故事？你如何确保这些故事符合一定的要求？

例如，在特性X的开发过程中，我发现了一些小的css bug。那么，作为开发人员，是否应该允许我将描述bug的故事添加到待办事项的底部呢？或者我应该和产品负责人讨论这个问题？

让所有的想法/bug都通过产品所有者听起来像是可能的瓶颈。

Answer 1

通常的方法是，任何人都可以在待办事项中添加故事。产品负责人对它们进行排序，团队对它们进行估计。在计划会议或回顾时，通常会以某种方式处理故事质量问题。

这意味着，只要您对产品所有者所分配的优先级感到满意，他就不会成为瓶颈。否则，提出你的理由。

Answer 2

无论我在软件开发领域做过什么，总是有一个类似于待办事项的列表，总是有一个bug报告列表，而且总是有人负责优先级(相当于一个PO)，所以您的问题，虽然使用了Scrum术语，但IMHO远远没有局限于Scrum。

谷歌快速搜索"scrum backlog bug“显示，一些团队将bug/问题从”新特性“故事中分离出来，而另一些团队则不这样做。有时使用问题追踪器，有时使用Wiki，有时所有东西都直接进入待办事项清单，等等，而且没有一致意见”哪个更好“。因此，首先您应该在团队中澄清如何处理这个问题，您的团队希望在待办事项中看到什么，哪些不想看到，以及您的团队认为什么最适合您的情况。

如果您有这样的体验，即如果允许每个人向待办事项中添加任何内容会使其变得一团糟，那么最好将用户故事与bug区分开来。一个好的bug报告应该是什么样的需求，这可能与一个新特性的良好用户故事的外观不同，这也可能是另一个原因。尽管如此，这两种技术最终都将成为开发人员的任务，这可能是将它们放在一个地方的一个原因。

然而，对于大多数产品来说，当任何人(用户、测试人员、开发人员、营销人员、注意到潜在问题的人)都可以提供bug报告时，这是有意义的。在将新特性添加到待办事项时，可能应该与PO讨论，作为过程的一部分。你的邮递员应该决定他是否要自己把故事放在那里，以便事先做一些编辑工作，或者是否有人能把这些故事放到积压的地方，然后再做编辑工作。但是对于bug，特别是那些在记者看来很严重的bug，不需要讨论将它们添加到问题跟踪器、积压文件或错误列表文档中，或者任何保存它们的地方。“不讨论”并不意味着将bug报告静静地放在任何地方，恰恰相反。当一个错误报告被添加，并且记者认为它可能不是一个次要的报告时，PO (或负责的人)必须得到通知。

最后要指出的是:要为团队做出正确的决定--如何管理这个问题--你的产品有多大，有多少人会报告错误和新故事，如果你每周报告一次，就会有十几个或几百个。

Answer 3

我们允许为团队中的每个人在产品待办事项的底部张贴bug。项目应该符合某些规则(例如，复制的条件、正确的行为等等)，但是，新特性被添加到单独的列表‘设想’中，PO将它们从其中提取为待办事项(如果需要更多的信息，显然会将它们转化为PBI )。