Not assigning Bugs to a specific user

Question

My question: Is there a benefit to NOT assigning a Bug to a particular developer? Leaving it to the team as-a-whole?

Our department has decided to be more Agile by not assigning Bugs/Defects to individuals. Using Team Foundation Server 2012, we'll place all Bugs in a development team's "Area" but leave the "Assigned To" field blank. The idea is that the team will create a Task work item which will be assigned to an individual and the Task will link to the Bug. The Team as a whole will therefore take responsibility for the Bug, not an individual, aligning to Scrum - apparently.

I see the down side. The reporting tools built into TFS become less useful when you cannot sort by assigned vs unassigned, let alone sorting by which user Bugs are assigned.

Is there a benefit I'm not seeing? Besides encouraging teamwork by putting the responsibility on the team-as-a-whole instead of an individual?

Answer 1

The idea is that the team will create a Task work item which will be assigned to an individual and the Task will link to the Bug.

So there will be an individual assigned to the bug and thus the only question is if that information is put in the bug tracking system or not.

You are in the situation where you have several systems handling related things and you wonder where to put things which could be set in several. Having redundant information is bad (it has a tendency to desynchronize itself, especially if the link is manual), but not having the needed information where it is needed is often worse.

The question is now about the purposes of a bug tracking system. For the team, it is a way to manage bugs. But it also often a way to communicate with the requester and if you are using it that way, not filling fields in the bug tracking system (let it be assignee, planning information, suggested work-arounds or whatever) will break that communication and leaves the impression that the bug is ignored, especially if the information is now available only in a system which is not accessible by the requester. And if the bug system is used to track who has the right to access customer data under NDA related to the bug, you'll have to fill it.

TLDR: that will depend on what you are using your bug tracking system for, in the flows I'm familiar with, it would not be wise.

Answer 2

If there are multiple team members that are capable of working in each area of the software, then one advantage of not assigning issues to individual developers is that you don't have to think explicitly about the possibility that certain developers would get overloaded with issues, because they are the natural choice for most of them. Instead, the workload tends to get distributed more evenly over the whole team, because everybody picks up what he thinks he can handle.

---

To keep the reporting tools more useful, I would recommend against creating separate Task work items. Instead, when a developer starts to work on a Bug, he should assign the Bug to himself to make it clear that he is working on that item.

Answer 3

Once a team member decides to take on the task to fix the bug, every one should know. Otherwise, you could end up with multiple devs fixing the same problem. If something comes up, take yourself off of the task.

Management has to buy into the idea regardless of reporting. If Team A is comfortable with Developer X never fixing bugs, that's fine as long as they don't turn-around and blame poor team performance on this fact.

The philosophy is all well and good, but there has to be some management oversight. This is important when there is a certain bug no one wants to fix (too complicated, bad legacy code, or one of those "sometimes" bugs.). Either prompt for volunteers or assign it.

The goal is to get things done. You can't use "we're agile" as a reason for failure.

Answer 4

I try not to think of the assignment of a User Story or Bug as assigning sole responsibility to one developer. Try to think of it as assigning someone who is responsible for driving the effort required to resolve it. Anyone can be pulled in as necessary and could be potentially assigned a task to capture that effort.

For larger teams that use Area Paths driven by sub-teams, you can leave a Bug or User Story unassigned but attached to a team-based Area Path.