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.
Best Answer
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:
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.