Should a developer close a ticket in a bug tracking tool? Or should only the scrum master or testers should do it?

What are the best practices?

  • Can a developer close a ticket? That depends on how the bugtracker is configured. Should a developer do so? That's a rather opinion-based question.
    – Philipp
    Oct 10 '13 at 7:29
  • Hi @Ads, I edited your question to make it more clear and less opinion-based.
    – superM
    Oct 10 '13 at 7:41
  • Definitely not a scrum master. That's not what scrum masters do. Nov 24 '16 at 13:54

Like everyone else has mentioned, it depends on the company or house rules of the team

but according Joel's post: Painless Bug Tracking

Bugs should be closed by the issuer of the bug to make sure that the bug is indeed fixed. So in your case, should a developer close the ticket? Yes, if the developer is the one who raised the bug ticket.

  • 2
    +1 The ticket should only be closed when the person who issued the ticket is satisfied. Oct 11 '13 at 0:16
  • What if the bug has been found by customers?
    – mouviciel
    Oct 11 '13 at 4:51
  • It would depend on the company on how bugs from customers will be handled. But in the case of my answer, the customer should be given the opportunity to close the bug report once the bug ticket has been marked as resolved. Maybe give them a time limit of 2 ~ 4 weeks, before asking someone else(PM/testers/etc) to close it. Although this might be in conflict with my answer, it can be a bad thing to keep things marked as outstanding for extended periods of time especially when the customer that reported the bug cannot be bothered to close it.
    – Maru
    Oct 11 '13 at 5:14

At the company I work at only a pm can close a ticket. The developer can set it to resolved though.

They to this so that every fix gets a check from the pm.

But it depends on the company.

  • Does pm stand for "project manager"? Nov 24 '16 at 14:20
  • Yes @TulainsCórdova , I should have written it out to make that clear, apologies :)
    – Agilix
    Dec 4 '16 at 9:00

It fully depends on the policy applied in your team.

And this policy may evolve with the progress of the project.

In an agile team, this can be discussed at the start of each sprint.


The exact procedure will depend on your team structure, the nature of the development you are doing (bespoke apps for clients, web application used by the general public, internal tools, etc.?) and the point in the development cycle (pre-launch, maintenance of production system).

But as a general principle I would say that the person who should actually close a bug ticket should be the person (or member of the team) that opened it.

So if this ticket came from QA, the developer should mark it as resolved and assign it back to QA, but it should be a QA person who actually verifies the fix and closes it.

In pre-launch phase, it might well be the PM who opened the ticket, and who should close it.

And of course it could be a developer. When I find a bug whilst working on something else, I create a bug in our tracking system, and then it's often me that fixes it, in which case I'll close it myself. But depending on team size and formality of development, you may wish to even assign cases like this to QA so they can verify the original bug, verify the fix, and close the ticket.


Opposed to several answers here: in case it is an end user who raised the ticket, he should not held to be responsible for closing it.

When a problem occurs, most users have interest in getting a developer to fix a problem. That is why they are motivated to raise tickets in first place. However, they have absolutely no interest in closing the ticket, because it just means extra work for them, with no substantial benefit (quite the opposite, by closing the ticket, they take some unwanted responsibility for signaling the problem is fixed now, which would mean they have to test the issue thoroughly).

So whoever in an organization is responsible to talk with the users and to manage their issues, that should also be the one who closes the user tickets. Such a procedure might include to tell the user "hey, we fixed the issue. Would you please give us a response within the next week?", and when the user does not respond any more, the ticket gets closed.

This is of course differently when the ticket came directly from tester: when a tester is told "the issue is fixed", it is typically his responsibility to make sure it is really fixed, and so he should be the one who closes the ticket.


Depends on the processes within your team.

I would close a bug off only if I executed acceptance test and verified that the bug has indeed been fixed. Even then, depending on the severity of the bug I would probably run it past the quality assurance lead.

I normally don't get SCRUM masters involved with bug fixing/testing as it's not their job.

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.