我们的主管心态是,如果将来发现一个错误,他想要这样做:找到描述无法正常工作的功能的PBI。将PBI更新为当前的Sprint。…
我工作的很多团队都采用以下两种方式之一对错误进行分类:
对于sprint中发现的错误,他们将它们与工作项相关联。所有其他错误都被视为独立的待办事项。
这有几个原因,包括:
除非您特别需要将错误与工作项相关联(例如,它是计费机制的一部分),否则您对此所做的任何努力都可能被视为浪费。将冲刺中的错误与工作项相关联不需要太多努力,因此不会产生太多浪费。使用sprint项目来做这件事通常是非常昂贵的,并且可能很难证明。
实际上,您只需要关联工作项(PBI> Bug> Task)。创建关联后,您可以在其下找到链接的工作项 的 相关工作 强> 。
在我看来,两种选择都可以。您提到的两个选项仅反映了积压和板上显示的工作项。但是,如果你已经链接了相关的 PBIs , Bugs , Tasks ,然后打开任何工作项,你可以找到它们之间的关系( 的 父/子 强> 〜虫子来自哪里)。
PBIs
Bugs
Tasks
例如:
Bugs are managed with requirements
Bugs are managed with tasks
的 更新: 强>
他们两个都不能 的 完全实现 强> 您的要求(没有更好的方法来实现基于当前功能)。
但是,如果你更关心bug的来源,那么 的 选项2 强> ( Treat the Bugs as a Task )更好,因为它可以在积压中直观地显示依赖关系/关系(Bug在特定的PBI下)。
Treat the Bugs as a Task
如果您更关心工作项的层次结构,那么 的 选项1 强> ( Treat Bugs at the same level as PBIs ) 更好 ( PBI > Bug > Task )。
Treat Bugs at the same level as PBIs
PBI > Bug > Task
无论你通过什么方式找到bug来自哪里 related link 。
related link