我们正在使用TFS 2013和最新的Scrum模板。 根据我的理解，错误和PBI在积压中处于同一水平。
但是如何处理在“准备测试”的PBI中冲刺期间发现的错误/问题？
当开发人员完成PBI时，他会在看板中将其从“进行中”移动到“准备测试”。
然后我们的测试人员使用Microsofts Test-Manager测试这个PBI（用户故事）。当他们发现问题时，会创建一个新的bug。这样做的好处是，我们可以在bug工作项中自动获得观察到的问题的良好文档。
但从我的观点来看，这不是一个错误。它只是一个未完成的PBI！
这种方法的主要问题是，它很快就会使看板和待办事项混乱。
在这种情况下，最佳做法是什么？ 在这种情况下，是否有某个指南/白皮书？
或许我们只是以错误的方式使用Test-Manager？
答案 0 :(得分：1)
我完全同意你拥有的是未完成的PBI。我认为事情可能出错的地方是开发人员有效地“将PBI交给”进行测试。
以敏捷或Scrum的工作方式进行切换，签字或“传递接力棒”都是无益的。我建议重点应该始终放在单个PBI上。别的都无所谓。只有在完成PBI时，开发人员才能开始处理另一个PBI。
因此，我鼓励开发人员在他/她开始处理其他任何事情之前，尽一切可能立即测试PBI。如果出现任何问题，开发人员会立即解决。这样你就可以避免你描述的情况。
答案 1 :(得分：1)
在PBI中创建新任务。对我来说，必须在“完成”中找到一个错误。工作 - 当故事处于开发阶段时，它只是在故事发生之前需要发生的另一项开发。
（我已将我的评论复制到答案中，因为人们似乎同意）。
答案 2 :(得分：0)
我们创建了一种名为Story Bug的新型工作项，它基于Task。这是一个故事中的一个错误，它将它与在故事工作之外发现的常规错误区别开来。
我们还为它创建了一个略有不同的工作流程：new - ＆gt;正在进行中 - ＆gt;错误已解决 - ＆gt;质量保证中的错误 - ＆gt;完成。
QA打开新状态的故事错误。然后开发人员将其移动到正在进行中，当他在芬兰工作时，他将其移动到bug解决。然后QA接受它并将其移动到QA中的bug，在那里他检查错误是否已修复。如果错误被修复，QA会将其移动完成;如果没有，他再次将它移动到新的。