Let's assume the situation where a team of four developers is building an application. During the testing phase, bugs are reported by users. Who should fix them? The person who committed the erroneous code, or anyone who is free?

What is preferred approach in agile development (scrum)?

  • 4
    He whom hath created thy code should fix thy code Feb 25, 2011 at 16:29

11 Answers 11


The preferred approach in agile development would be to get them fixed as quickly as possible, by whomever is available. This is simply because the ownership of the code does not fall to any one person, but to the entire developer group. If one individual is consistently causing bugs, that is another issue that needs to be addressed separately.

  • 1
    +1 for "as quickly as possible". Indeed, fix them as soon as you can and let your users to continue testing, and report new bugs.
    – yegor256
    Feb 24, 2011 at 21:05
  • 1
    And what about feedback to the person who commited the bug?
    – Robert.K
    Feb 25, 2011 at 7:26
  • @Robert it's not a matter of just feedback. The bug has to be formally closed by the submitter.
    – yegor256
    Feb 25, 2011 at 7:52
  • 10
    Also fixing other people's bugs is a great way to learn. Because you didn't write it, it forces you to really understand what the code is doing.
    – AndrewKS
    Feb 25, 2011 at 16:06
  • 1
    @yegor, robert asked about the person who wrote the bug, not the submitter. For important bugs it should be reported, for trivial ones not.
    – user1249
    Feb 25, 2011 at 20:05

By default the person. The reason is quite simple: feedback. Bugs provide a great opportunity for personal and professional feedback. If someone else fixed my bugs, I would make the same mistake again, because I wouldn't learn from it.

If that person is not available, somebody else can fix it, but the person should follow the bugs life cycle.

  • 3
    That is why communication is important. If a person who fixes the bug who is not the original coder explains what the problem and fix was to the originator, then two people learn from it, rather than one.
    – AndrewKS
    Feb 25, 2011 at 16:08

As a PM I would avoid linking bugs to specific developers. If it needs to be done let the functional/development manager do that. Concern yourself with the team. There is a bug the team needs to fix.

  • What we do is we have a generic assignee that we call "Client Developer" which could be anyone in the team and in triage we will have a flag that will show all issues assigned to that user. That being said, it is important that you do eventually assign these tasks/bugs so people take responsibility for them.
    – aug
    Mar 7, 2017 at 8:36

I don't know how scrum handles this scenario, but in my team, we have something like a cross testing / code review. This way, in case a bug is found, both the developer and reviewer discuss the best approach to fix it.

I believe that, as long as the solution fits, does not matter if the developer or reviewer applies it. Is important however, to avoid any kind of conflict between developer and tester.


Edit: Not sure if I made myself clear, but is important to highlight that the reviewer is another developer in the team.

  • @Tiago: I appreciate your solution, but I don't think the discussion is always necessary. Feb 25, 2011 at 7:08
  1. Evaluate the bug
  2. If it will be faster/make more sense for the original developer to fix it, give it to them
  3. If it can be fixed by anyone on the team, let anyone do it.

I totally agree with Steven about the code belongs to all team; and there's some more reasons that you shouldn't give the bug to their creators:

As I know, in many cases it's hard to identify who caused the bug. Even if you are using a document management system like SVN, tracking down the error code may consume lots of time. So, in my view, just give the bug for anyone who are free.

If you want to track how the bug produced, in leisure time you can ask the repairer about the case (before all team). As your team is small, I think this would share the experience about possible bugs, and not make anyone embarassed.


There are only three reasons to care about who fixes a bug: cost, speed and professional development.

And there are pros and cons for all three. For instance professional development, on one hand it's an opportunity to learn more about the code on the other it's an opprtunity to recognize the kinds of mistakes you make and avoid some in the future. Or take cost, presumably the one that made the mistake would be able to fix it faster, and probably cheaper, on the other hand there's a cost for the time spent identifying who made the mistake, and assigning it to the appropriate person -- time which in a lot of cases exceeds that of fixing the bug.

The agile approach is to let the developers self assign the problem, I would override that only for a good reason.


In my team, we always decide according to priority. if the person who submitted the code is available, he/she fixes the code. If that person is working on some higher priority story, anyone who is available and can fix the code as soon as possible will fix it. If everyone is busy with working on higher priority tasks in the current iteration, the fix is scheduled in the next iteration according to its priority as compared to the other stories and defects.


Think about: Who has more information about the bug? The development team.

So let they decide what to do with the bug. They own the code, so they are responsible for it.

You can help them by managing the project, allocating some time on project scope for bug fixes and letting they alone to do the job.

Avoid taking to many decision where you (as PM role) has less information than the team.

See the question about: How to Avoid Micro-Managing a Software Development Team?


I say, you need a bug tracking system, to record bugs, caused by what, reported by, and then assign the bugs, to different people based on their work load. Also indicated whose code caused the bug, and then have a report showing how many coders, and what apps, have caused x number of bugs during the week.

Then you can show that to coders, to show how they are causing bugs.

And the best way to prevent bugs, is to get everyone involved with fixing them. I mean assign a bug fix to different people, to give round-out experience of what causes bugs and what fixes them.

Then maybe after a month or two of everyone fixing bugs, revise or create your coding style guideline to help prevent future bugs, system wide, by having written/documented standards for how you program.


When a bug is found, it is the responsibility of the whole development team to fix it.

If people believe that a bug should be fixed by its author, it is like saying "I'm not fixing the problem, the hole's not on my side of the boat". But the boat will still sink if the hole is not fixed, and you are on that boat with everyone else.

Individuals need to realize that they are part of a team and understand that the code, along with its responsibilities, belongs to all of them. The success of a project rests on all team members.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.