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.

  • 1
    Where did you find a clue in that article that triage is performed in meetings? A triage is a decision the responsible person (in Scrum the product owner) makes. Whom he has to talk with for making that decision, for how long and how formally depends fully on the issue and the organization. Note further the article talks about "emergency issues", but avoids the term "bug". – Doc Brown Aug 10 '15 at 20:49
  • It seems to be like both quotes are referring to the Product Owner performing triage. In one case, real (critical?) production issues can be added to the sprint and fixed with the rest added to the product backlog and prioritized appropriately. In the second case, no issues are ever added to the sprint, but would be added to the backlog and prioritized. – Thomas Owens Aug 10 '15 at 20:55
  • At the risk of overreacting to a non-critical point, if there's a genuine emergency (e.g. the product is crashing on startup for multiple clients) then we don't hesitate to drop the whole agile sprint thing and fix it right effing now. The product owner may not be around at the time, but it's not that hard to tell the difference between a genuine emergency and a "top of the backlog" issue. – Ixrec Aug 10 '15 at 22:04
  • I've heard of "triage meetings" all the time, where QA and sometimes developers get together, look at open issues, and decide if it's a valid issue or not. Close them, assign target versions, etc. Maybe the kind of triage the article is talking about is more agile-specific? – void.pointer Aug 10 '15 at 23:36
up vote 6 down vote accepted

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.

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.

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.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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