Edit: Definition of "bug". Here I describe as bug a bug introduced during development or missing/incorrect implementation of a story found after acceptance of the story. Our team does not face "production bug" reported by users.

At work we often have the following situation:

  1. Team member find a bug
  2. Bug is forwarded to PO and Scrum master
  3. PO set up a meeting with scrum master, team member who found the bug, themselves (and some times more team member)
  4. A long discussion ensue to discuss what happened, what should have happened, is it a bug, how to fix it, when to fix it.

The problem I see is that too many people are put in a meeting to discuss too many details.

What I think would be better:

  1. Team member find a bug
  2. Team member try to reproduce the bug and details how to reproduce it.
  3. Team member discuss with other team member/scrum master how to fix the bug.
  4. Scum master discuss with PO when to fix the bug.

Is the current situation good or could be improved? Is my solution a correct solution?

  • 2
    Hi Jason, welcome to PM.SE! Shouldn't "Team member try to reproduce the bug and details how to reproduce it" a part of "Team member find a bug"? I mean, if the team found a bug, I'd say it'd be ok to invest 15 or 30 min to confirm that's a bug and reproducing it.
    – Tiago Cardoso
    Commented Apr 25, 2019 at 8:39
  • Yes it should, but often it stops at "I found a bug when I did this". Not taking account context, does it behave the same way in other cases, etc. I could summarize this by "we don't collect enough information on the bug before telling someone to fix it"
    – JayZ
    Commented Apr 25, 2019 at 8:54
  • What is the position of your Scrum Master? Based on the normal responsibilities for a Scrum Master, I see no reason for them to be involved in what to do about specific bugs or how to fix them.
    – Erik
    Commented Apr 25, 2019 at 10:02
  • May these help you: pm.stackexchange.com/questions/12743/… or pm.stackexchange.com/questions/8098/…
    – Krunal
    Commented Apr 25, 2019 at 10:24
  • I think the way you're classifying "bugs" is problematic at best. There's a difference between stuff related to the Sprint Goal and the Definition of Done, and new work that's uncovered. Your process sounds both misguided and too heavyweight, but it's hard to say for sure since you haven't explained why the team has developed the current process.
    – Todd A. Jacobs
    Commented Apr 25, 2019 at 15:17

3 Answers 3


TL;DR: A bug should always go to Product Backlog. If you cannot afford it, get ready for unplanned work and bring it during next retro to agree a new workflow.

Both flows presented are both creating unplanned work during the actual Sprint. That's because you're dedicating time (either on meetings or on detailed analysis) on something that was not planned. In a proper Scrum team, that's unlikely to happen - not only because it breaks the cadency but also because a seasoned Scrum team has a considerable amount of automated tests done.

Worth to review How to handle bugs in Scrum. Bugs, as any other feature, should go into the Product Backlog and then, prioritised by the PO.

However, there may be cases where bugs are found and must be dealt with ASAP. In that case, I'd suggest you to take a look at how to work with sprints having to provide support to unplanned issues.

If that's your case and you have to deal with bugs ASAP in a fairly constant basis, then your workflow may work. Your focus should be on finding the leanest way to tackle it. Before presenting your solution, state the problem during the next retrospective meeting. Tell the team you have a proposal. Don't try to force your workflow - instead, ensure that the team feels that this new workflow has been decided and agreed by the team. Otherwise they may resist on adopting it.


I could provide feedback on your current way of working and your proposed change, but it is better if the team are the ones making decisions rather than outsiders.

As a Scrum Team member you have made a suggestion to adapt your team's way of working.

Next steps would typically be:

  • Bring your suggestion to the team retrospective, or ask the Scrum Master to arrange a team discussion about this topic.
  • If the team sees value in your suggestion then perhaps propose trying this approach for an amount of time (say 2-3 sprints).
  • Decide as a team how you will tell if the change has made things better or worse.
  • Run the experiment and if things do get better than adopt this new way of working.

Scrum is all about inspecting and adapting. Get good at that and your team will thrive.


Your proposal has one thing that I found interesting:

Team member try to reproduce the bug and details how to reproduce it.

Does this mean that currently no information is stored on how to reproduce a bug? If you don't, start doing that! The team can define a minimal amount of information needed to be able to discuss it. Think of things like:

  1. A clear title
  2. A clear description of what happened
  3. Steps to reproduce
  4. Screen shot
  5. Whatever else the team thinks is needed

This would help to create a bug that is still understandable in 6 months, you can try to reproduce it then (because maybe it was fixed already) and still determine which other areas could be affected

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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