使用Scrum，有用户故事的原理和这些干预任务等等迭代到成品 - 这很好。
但是，假设我有100个需要实现的功能，在现实世界中我不能将任何开发人员放在这些上，直到很多正常的辅助工具完成 - 例如，做一个UI设计（当然你需要对此功能有一个全面的了解吗？），或构建不一定表现为功能的底层内容。
那么，这会发生在哪里？
答案 0 :(得分：9)
我的理解是，在scrum中，您只构建实现每个用户故事所需的内容。因此，只有在需要为您正在处理的用户素材实现功能时，才构建不是功能的基础内容。
答案 1 :(得分：9)
在我看来，非功能性任务仍然可以用于产品积压 - 当我使用Scrum时，我们肯定会这样做。我们必须向产品所有者解释为什么他们应该被视为重要，所以我们可以有时间去做。如果产品所有者不相信他们非常重要，他们就不会完成 - 并且所有者必须忍受结果。在通过驳回你对负载测试之类的请求而被叮咬几次之后，它会被淘汰，它们很可能会出现：）
另一方面，您可能会发现您最初认为某些非功能性要求非常重要，但可能会受到影响而无法满足。有时，有时，开发人员的直觉是错误的：）
对于真正的门控因素的任务，我认为你必须对产品所有者诚实，坚持你必须这样做。如果您无法继续使用产品所有者继续执行项目，那么遇到的问题比没有获得UI设计更大：）
答案 2 :(得分：4)
我会将辅助任务构建到需要它的第一个功能中。
区分产品积压和sprint积压之间的区别非常重要。产品待办事项包含代表“什么/为什么”而不是“如何”的用户故事。当为sprint选择故事时，故事会被分解为构建它所需的任务。例如：“UI设计”将是“选择要购买的物品”故事的任务。 sprint计划级别对任务具有依赖性没有任何害处;事实上，大多数时候会有一些任务可以让其他产品积压项目变得更轻松。
希望有所帮助！
答案 3 :(得分：3)
基本上，它发生在每个功能中，这说起来容易做起，但也许是敏捷增量软件开发的重点。
例如，不应该构建大量“不一定表现为功能的基础内容”，而应该怀疑自己不需要它，并且只能构建您需要的功能。问题
答案 4 :(得分：0)
在我看来，最好的做法是尽可能将“故事”包含在内，这样每个人都可以很好地了解时间的应用。
但是，总会有必须完成的计划外任务（例如，如果机器损坏，请重新安装）。对于那些任务，一个选项是在每次迭代中留出一定百分比的空闲时间，如果你每次迭代有300个故事点的速度，例如，最初只有250个故事点，留给计划外的东西，然后，在以下迭代中，您可以根据过去的历史记录调整这些值。