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)?

  • 5
    He whom hath created thy code should fix thy code Commented 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
    Commented Feb 24, 2011 at 21:05
  • 1
    And what about feedback to the person who commited the bug?
    – Robert.K
    Commented Feb 25, 2011 at 7:26
  • 1
    @Robert it's not a matter of just feedback. The bug has to be formally closed by the submitter.
    – yegor256
    Commented Feb 25, 2011 at 7:52
  • 14
    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
    Commented Feb 25, 2011 at 16:06
  • 2
    @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
    Commented 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
    Commented Feb 25, 2011 at 16:08
  • "If someone else fixed my bugs, I would make the same mistake again"- that heavily depends on the root cause of the specific bug. If my bug was just caused by a typo, someone else can easily fix it, no feedback required. If I had a small misunderstanding of the requirements, or just missed a test case, it is best to fix the bug by myself once that misunderstanding was clarified, for the reason you mentioned. But in case I had a fundamental misunderstanding of the requirements, some other dev who has a better understanding than me may be able to show me in code how to fix a bug correctly.
    – Doc Brown
    Commented Jul 19, 2023 at 12:20

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
    Commented 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. Commented Feb 25, 2011 at 7:08

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 for someone else to learn more about the code on the other it's an opportunity for the one that made it to recognize the kind of mistakes 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.


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.


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.

  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.


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?


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.

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