如何定义对用户没有感知价值的 PBI？ [关闭]答案

【问题标题】：How to define a PBI that has no perceived value to the user? [closed]如何定义对用户没有感知价值的 PBI？ [关闭]
【发布时间】：2013-06-25 02:38:09
【问题描述】：

我需要在我们的产品待办列表中添加一个对用户没有（感知）价值的项目。

上下文：每周我们都需要解析和导入我们系统的 TXT 文件。现在提供者决定将格式改为XML，所以我们需要重写解析引擎。

最终用户不会看到任何好处，因为他会继续获取他的新数据，但我们仍然必须这样做才能继续导入数据。

如何将这样的项目添加到产品积压列表中？

【问题讨论】：

什么是 PBI？产品待办事项？
@Dave Hillier 准确地说。
我投票结束这个问题，因为它与编程无关。

标签： agile scrum user-stories

【解决方案1】：

如果您不进行更改会怎样？防止这种情况发生对用户有价值吗？如果答案是肯定的，我建议将您的商业价值声明与此联系起来。然后，您可以编写具有商业价值的典型用户故事，并像对待任何其他 PBI 一样对待它。

【讨论】：

如果我们不更新格式，我们将无法更新客户的记录，因为 TXT 格式将被停用。我应该在问题中这么说，但这在某种程度上是我们系统中的核心功能。
这就是答案。商业价值在于，该软件可以在未来使用。

【解决方案2】：

它对用户没有价值，但对你的公司有价值。

作为 X 公司，我希望能够支持新的 XML 格式，以便我可以继续从提供商 Y 导入数据。

听起来怎么样？并非所有故事都必然围绕最终用户发展。

注意：技术故事和技术改进故事不是一种好的做法，应该避免。为什么？因为您无法正确确定它们的优先级，因为它们没有可估量的价值。
做技术故事的正确方法是将它们包含在完成的定义中。例如：决定每个新故事只有在通过 Dapper 而不是 L2S 访问数据库时才完成。这是一个可行的 DoD 定义，并确保您可以适当地改进您的系统。

【讨论】：

似乎他的更改需要相当多的返工，并且应该引发彻底的重新测试。你会根据哪个项目预订这项工作？你要拿起的第一个项目，不管它是什么？您将如何跟踪所有更改是否都经过正确测试？
我不明白您的评论：问题中只有一项。
是的，但您回答说，为这样的技术批准提供故事并不是一种好的做法。您建议将它们添加到国防部。但是您不希望像 PBI 这样可追溯的重大更改，以便您可以相应地跟踪它们吗？
我不明白。您希望拥有一个可实现的 DoD，因此您必须将重构的规模限制在易于处理的范围内。国防部中包含的所有内容都是针对每个故事完成的。例如。如果您添加“故事应该进行单元测试”，那么对于您播放的每个故事，您都为该故事添加单元测试。如果您需要做很多工作才能将单元测试添加到单个故事中，那么您不应该拥有那个 DoD，您应该添加一些可实现的东西（例如，如果您的代码不可处理，它可能是一个集成测试） .
我认为用户是一个真实的人使用系统，但实际上用户是与故事相关的，所以它可以是一个真实的用户，一个系统或任何形式的交流。这不仅仅是技术上的改进，因为 TXT 格式将被停用，因此我们需要解析新的 XML 格式。

【解决方案3】：

我们通常只是将其添加为“技术改进”，并给予我们认为合适的优先级。如果用户问你这件事，你只需向他们解释一下这个改变做了什么以及为什么需要它。

不要忘记，如果您不进行更改，您的应用程序将来很可能会开始失败。只是告诉他们，让他们决定是否想要。

【讨论】：

虽然我同意你的观点，最终我们需要更新解析引擎以使系统继续工作，但我试图留在 scrum 边界内并确定一个为用户增加价值的故事和不仅仅是从技术角度来看。
没有明显的附加价值：系统一直在工作。如果你不做这个故事，系统就会停止工作，...
我会投反对票（没有足够的代表），因为添加“技术改进”的团队违反了产品负责人对产品积压的责任。如果 PO 认为“更改 XML 格式”没有任何价值，则不应这样做。团队要学会尊重PO，PO也要学会尊重团队。
但是在这种情况下，您显然可以清楚地解释 XML 格式需要适应您正在使用的一方将其更改为的内容。不更改 XML 格式会破坏应用程序。