PBI vs用户故事

最近，产品负责人已将一个项目添加到产品待办事项列表中，该项目显示“当我从x页面转到登录页面时，我看到一个错误。我希望删除该错误”。

在我看来，这不是用例，也不应该是PBI（产品积压项目）。但是，当我讨论它时，Scrum管理员告诉我用户故事不是PBI，而PBI可能是错误报告，任务，用户故事，任何东西以及实际上应首先解决的任何项目。

我对此不确定。而且我在网络上找不到很好的PBI定义。因此，我的问题是，什么样的事情可以作为项目进入产品待办事项列表？产品积压项目是否映射到用户故事？他们是一样的吗？

产品积压项目是否映射到用户故事？他们是一样的吗？

不一定，但是总的来说，它们确实如此。就像您的Scrum管理员所说，其他事情也可以是产品待办事项。然而，这取决于如何你 SCRUM工作。一些团队有一个单独的bug待办事项列表，冲刺也将其考虑在内，而其他团队则将此类事情保留在产品待办事项列表中。

两个单独的日志使产品负责人难以确定任务的优先级，因为现在必须考虑两个日志才能进行下一个冲刺。但是，它们确实提供了更好的监督，并且可以分别对它们进行优先级排序。

因此，我的问题是，什么样的事情可以作为项目进入产品待办事项列表？

这可以是产品构想以及要创建产品的过程的一部分。它主要包含需求（用户故事），但也可以包含不直接属于产品的操作或技术性东西（例如“为开发团队购买新服务器”，“为产品创建广告”）。积压的订单应避免不必要的细节，并且不应尝试对技术进行微观管理。产品积压中可以包含任何能为产品带来价值的东西。

没有一个真正的Scrum。有时，单独的待办事项是管理产品的更好方法，有时它们只是一种方式。找出最适合您的方法。

处理错误时，我们将它们添加到积压中，并称为错误故事。通过以这种方式在待办事项列表中添加错误修复程序，很明显这不仅是错误修复程序。我们可以添加其他任务来确保编写自动化测试并完成验证。这也使应该遵循DoD更加明确。

我们从未使用过PBI一词（即使我们的积压工具称其为“ PBI”），它始终是用户故事，错误故事或仅仅是故事。

这主要是您团队选择的术语，只要您清楚什么才是真正无关紧要的。

以上所有答案均未引用Scrum框架的权威源文档：The Scrum Guide。

产品积压

有一节描述产品待办事项及其中包含的项目（通常称为PBI）。

产品待办列表列出了所有功能，功能，要求，增强功能和修复，这些功能，功能，要求，增强功能和修复程序构成了将来版本中要对产品进行的更改。

但是并没有像项目计划那样固定。

产品待办事项随着产品和使用环境的发展而变化。产品积压是动态的；它会不断变化以识别产品需要合适，具有竞争力和有用的产品。

用户的故事

用户故事一词从未出现在《 The Scrum Guide》中，因为

它是一个框架，您可以在其中使用各种流程和技术。

使用用户故事只是记录PBI的一种可能技术。

另外：尽管通常看到“按我想要的形式”格式，但它可能违背了其最初的意图。敏捷2017也解决了这种麻烦的格式。

@Falcon已经很好地解释了。具有正式定义的页面是：http : //en.wikipedia.org/wiki/Scrum_( development)#Product_backlog至少根据该描述，您所描述的内容不会放入产品待办事项列表中。

有一个普遍的误解，即在产品待办列表中仅允许用户故事。相比之下，Scrum在需求技术上是中立的。正如Scrum Primer所述，

产品待办事项以清晰，可持续的方式进行表述。与流行的误解相反，产品待办列表不包含“用户故事”；它只包含项目。这些项目可以表示为用户案例，用例或小组认为有用的任何其他需求方法。但是无论采用哪种方法，大多数项目都应着重于为客户创造价值。*

• 产品更改和添加的不同规范称为产品待办事项列表（PBI），它们共同构成了产品待办事项列表。
• 每个PBI都描述了开发人员可以开发并交付的内容，以在完成后为相关的利益相关者增加价值（请参见完成的定义）。
• 最常见的利益相关者是市场或其代表-产品所有者。
• 但是，PBI可能描述了可以降低企业成本或减少开发团队工作量的工作，或者描述了可以帮助产品所有者团队更好地完成其工作的工具。
• PBI可以描述对利益相关者具有潜在价值的任何事物。

（用户）故事是积压项目的有用的标准格式。它的基本原理是“如果没有人关心它，不要浪费时间”。它也使PO可以评估项目的紧迫性，因为它定义了将要针对谁以及它有多糟糕。

就您而言，该错误可以轻松地格式化为故事。

• 作为用户
• 我希望能够从第X页登录（而不是收到错误）
• 这样我就不会浪费时间，不会因为烦恼而对产品失去信心

听起来这值得付出一些努力。