Jira Triage meetings should review all issues with a 'Fixed Version' of Triage, this should be all new issues as well as older issues needing team input.

When to have Triage meetings:

  1. The Triage meeting should be handled separate from the daily Scrum meeting.
  2. During the testing phase there should be a daily Triage meeting.
  3. When not in the testing phase, Triage meeting should only occur a couple of times a week, suggest Tuesdays and Thursdays. This is to avoid burnout and let some issues pile up for discussion.

Who attends Triage meetings:

  1. Suggest a QA person runs the Triage meeting.
  2. Triage meeting should be attended by all interested parties, which should consist of QA testers, developers and anyone else interested - really any team member concerned about the project should consider attending. Scrum master should attend regular Triage meetings when testing is primary activity.

How are Triage meetings run:

  1. Person running Triage meeting should review all issues in the Triage queue before the meeting to be able to discuss. This could be as simple as reading to understand but may also require a quick double check or talking to the issue writer, this helps the meeting move along. Minimally QA testers should review the issue list before the meeting as well as whoever is running the meeting. (Suggest developers wait and review Triage list right before the meeting to keep from 'trolling' for new issues.)
  2. Running the meeting should consist of someone reading the issue number, the title and a brief description of the problem if needed.
    a) Team members should make sure they understand the requested change to make sure the change makes sense. Change requests can agree with or may be the opposite of previously received user feedback, so the intention of the change may need to be debated.
    b) Team members should think about possible ramifications of the requested change.
    c) Team members should make sure a noted bug is really a bug - sometimes what one team member views as expected behavior another team member has just written as a bug. The team should come to a consensus on this. It's the customer's responsibility to give final say on these.  Suggest taking these issues offline for customer review if customer is not present for the Triage.  The scrum master should not proxy for the customer.
  3. During the Triage meeting, team members may request additional testing with specific notes added and then have the issue reviewed again at the next Triage meeting.
  4. Person running the Triage meeting, or someone else, should take notes and update issues in Jira immediately after the meeting. Jira updates should include a comment to detail what's being changed, i.e.: Changing to Robin, Product Backlog as per Triage meeting 12/21/07.
  • No labels

1 Comment

  1. Alan Liggett

    I'm not sure how often Triage meetings should be held. Currently they've become the first part of the daily Scrum meeting. Some developers have commented that they like it here, as they don't have to attend an additional meeting. For me, I like the efficiency but I feel any discussion is rushed and I feel many of the items should be discussed (dev/QA discussion is being missed which typically could cover other potential problem areas). I also don't like having the same exact process all the time as team members can get burned out (I know I can).
     My preference would be to have Triage meetings a few times a week during testing, maybe just once a week when we aren't in testing (question). My thoughts are that issues should be allowed to build up a little then reviewed bunches at a time, with major problems being discussed immediately.