How should be best discussed bug between team/scrum master/PO

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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