-5

Our Supervisor mentality is that if a bug is found in the future he wants to do this:

  1. Find the PBI that describes the functionality that is not working correctly.
  2. Update that PBI to current Sprint.
  3. Create a Bug and put it under that PBI.
  4. Create a task and put it under that Bug.
    • The rationale behind this is that he considers that PBI to not have correctly finished, so it has to be re-opened, and he wants the Bug to be under that PBI so that he knows what functionality was not working correctly.

I'm under the impression that the correct way really only has 2 options:

  1. Treat Bugs at the same level as PBIs when you find them in a future iteration - create the Bug but just be as descriptive as possible so you know what functionality was the problem.
  2. Treat the Bugs as a Task, so either create a new PBI, or copy\move the previous PBI to the current sprint, and put the Bug under that PBI, but DON'T create a task under the Bug, the Bug essentially is a task.

What would be a solution for our shop?

Angel Cloudwalker
  • 2,015
  • 5
  • 32
  • 54

2 Answers2

1

Actually you just need to associate the work items (PBI > Bug > Task). Once the association is created, then you can find the linked work items under Related Work.

In my opinion, both options are OK. The two options you mentioned only reflect how the work items shown on backlogs and boards. But if you already linked the related PBIs, Bugs, Tasks, then open any of the work items you can find the relationship between them (Parent/Child ~ where the bug came from).

For example:

  1. Treat Bugs at the same level as PBIs (Bugs are managed with requirements)

enter image description here

  1. Treat the Bugs as a Task (Bugs are managed with tasks)

enter image description here

UPDATE:

Both of them can not completely achieve your requirements (No better ways to achieve that based on the current features ).

However if you are more concerned about where the bugs come from, then option 2 ( Treat the Bugs as a Task) is better, as it can show dependencies/relationship intuitively in backlogs (Bug is under specific PBI).

If you are more concerned about the hierarchical structure of the work items, then option1 (Treat Bugs at the same level as PBIs) is better (PBI > Bug > Task).

Whatever you can find where the bug comes from via the related link.

Andy Li-MSFT
  • 28,712
  • 2
  • 33
  • 55
  • Indeed I would like the team to make good use of the board which is why I'd like to use one of the two options I mentioned. I noticed you put both are OK, is there a better best practice then? – Angel Cloudwalker Mar 29 '18 at 14:46
  • @MilesMorales Both of them can not completely achieve your requirements (No better ways to achieve that based on the current features ). But if you are more concerned about where the bugs come from, then **option 2** ( `Treat the Bugs as a Task `) is better, as it can show dependencies/relationship intuitively in backlogs (Bug is under specific PBI). If you are more concerned about the hierarchical structure of the work items, then **option1** (Treat Bugs at the same level as PBIs) is better. Whatever you can find where the bug comes from via the `related link`. See the updated answer. – Andy Li-MSFT Mar 30 '18 at 02:23
1

A lot of teams I work with categorize bugs in one of two ways:

  • Bugs found in a sprint on items worked on in that sprint
  • All other bugs

For bugs found in a sprint they associate them with work item. All other bugs are treated as stand alone backlog items.

There are several reasons for this, including:

  • When a bug is discovered some time after the work is done it may be difficult to work out which work item it is associated with
  • Not all bugs neatly associate with a single work item, particularly ones not found in-sprint
  • Bugs found in-sprint should be immediately addressed or the work items will typically not meet the definition of done
  • Bugs found out of sprint need to be prioritised alongside other work items

Unless you have a specific need to associate bugs with work items (for example it is part of a billing mechanism) then any effort you put in to this could be considered to be waste. Associating bugs in-sprint with work items does not require much effort and so does not generate much waste. Doing it with out of sprint items is often quite costly in time and may be difficult to justify.

Barnaby Golden
  • 4,176
  • 1
  • 23
  • 28
  • I'm getting the sense that treating Bugs as stand alone items for the reasons mentioned above is best practice, especially if found outside of a Sprint. Should they be linked to features like PBIs? – Angel Cloudwalker Mar 29 '18 at 14:47
  • What value do you get from linking them to features? – Barnaby Golden Mar 29 '18 at 17:57
  • To get a sense of what functionality the bug is affecting outside of it's description? Or perhaps it'd be better to use the "Related" link option to link it to a PBI as "Related To"? – Angel Cloudwalker Mar 29 '18 at 18:12
  • I think I would tend towards the related link. But it's only worth bothering with if you get some value from it. I had one team that wanted to do some analysis of types of bugs against types of work items. That made it worth our while to spend time linking the bugs to work items. – Barnaby Golden Mar 29 '18 at 19:11