When to have bug triage meetings in SCRUM process?

Question

I was reading an article that explains some solutions to the "unpredictable emergencies" situation during Agile sprints. The article suggests having triage to determine if issues are truly emergencies and if they should be worked on by resources involved in an active sprint:

So solution 1 is: a strong Product Owner who performs triage on all production issues. If it's a real production issue then by all means fix it. But I can guarantee that you'll find a good number of issues that should not be emergencies at all... BTW, a Product Owner performing triage in this way is what James Coplien calls a Firewall in his organizational patterns book.

The article also mentions a "solution 2":

Solution 2: Perform Triage - And Defer The Fix Until At Least The Next Sprint

The one thing the article didn't go into detail on was the triage itself. Are these meetings, properly scheduled? Or are they "cubicle" meetings started on-demand, very informal, to discuss the bug with relevant parties? Who should be involved in these triage meetings/discussions?

My questions are more general. I'm not going to ask everyone here to read the long article itself. The question is generally in regard to bug triage in Agile process.

Answer 1

Triaging is not typically done as a meeting. Teams do it differently, depending on the product, but on our team, the product owner triages the customer issues, and we rotate another team member as "triager of the day" for issues that testing finds.

The triager's job is not supposed to be debugging, but answering the following questions as efficiently as possible:

• Is it a known bug, new bug, or user error?
• If a new bug, which software team should be responsible for the fix?
• How severe is the impact? Is there a workaround, is it preventing further testing, etc.
• Rough estimate of time to fix.

If the triager needs someone else's expertise, he calls him over. If the triager feels it's severe enough to put something else on hold, he will have an informal chat about it with the product owner. Otherwise, it goes into our backlog. Most of the time, triaging an issue takes maybe 15 minutes and doesn't require involving anyone else.

Answer 2

It depends.

Different agile teams have different processes because they have different needs. If you have a few dozen bugs coming in every day, an informal cube meeting is probably not going to cut it. If the majority of the bugs are user inputted, you need someone who just looks for dupes and can judge usability issues. If you're a small group, then stopping by the team lead's desk is good because then you can discuss needs and reproduction scenarios. If you're a few weeks before major scheduled release (yes, they happen in agile sometimes), you might need to triage more often,

What I've seen work best in average sized teams (5-7 devs) on average sized projects (9-18 months) without weird requirements (politics, governmental oversight, super high risk project, etc) is to have the triage meeting alongside your backlog grooming 1-2 days before sprint start. People can come by the team lead with things they think are more urgent (high impact customer issues, bugs blocking another team, data corruption). They then will make a call if the bug is severe enough - or the reporter trustworthy enough - that it shouldn't wait.

Yes, you should try not to interrupt the sprint, but people will do it, so might as well push them towards doing it the least disruptive way.

Answer 3

The first thing to say is that almost everything a Scrum team works on should be discussed in Sprint Planning meetings in the usual way. Whether a Story is a bug fix our new feature development, it is at this point that the Product Owner should put it in its place in a prioritised Sprint.

Secondly, disruptions to Sprints do occur - it's just a question of frequency. If it's an occasional thing, the team as a whole, including its Product Owner should be prepared for the Sprint to suffer, and the PO should be onboard with that before people start working on unexpected tasks.

The main thing you need to consider is: is Scrum right for you? It may not be. Novice PO's often go through a phase in the first couple of months of trying to game the system, to somehow get more work out of the team. I've seen newbie Product Owners describe the absence of a feature they thought of in the shower that morning as an urgent bug, in an effort to get more stuff onto the Sprint that the developers were prepared to commit to. If this is what's happening, sick with Scrum and break in your new PO as gently add you can. But if the nature of the team's job is that unexpected bugs, customer queries etc. need to be dealt with virtually every fortnight, I'd suggest that Scrum is not for you. Kanban is a system of Agile Methodology that is much more flexible, and genuinely values responding to change over following a plan in a way that Scrum doesn't, on a fine enough timescale. If you find yourself constantly trying to shoehorn emerging priorities into a system that doesn't really allow for that, try a different system.