...
- QA should review all issues in the Triage queue before the meeting.
- Note: Suggest developers wait and review Triage list right before the meeting or save time and just listen at the meeting.
- QA should run the Triage meeting.
- QA person should take notes; it's helpful to have a printed issues list.
- Triage meeting should run as:
- QA person reads the issue number, the title and a brief description of the problem if needed - just enough info until the issue is understood.
- Discuss if issue is related to another issue, a dupe, ask questions, request additional testing if needed, etc.
- Team should:
- Understand the issue to make sure change makes sense.
- Think about possible ramifications of the requested change.
- Make sure noted bug issue is really a bug (and not expected behavior).
- Make issue decisions:
- To be part of the current Sprint or which bucket it gets added to?
- Assign resource.
- If additional testing is needed, the issue could be reviewed again at the next Triage meeting or decided now.
- QA should should update Triage issues soon after the meeting.
- Assign resource, Fix Version bucket, etc.
- Include any relevant notes, link issue, etc.
- Updates should include a comment to detail what's being changed, i.e.: Changing to Robin, Codfish as per Triage meeting 12/21/07.
ROLES:
- Project Manager:
- Tracking status
- "The accountability piece": main artifact is the Burn-down chart
- Red flags (ie: people are going beyond what they estimated, totals add up to more time than is allotted, etc) should be raised to Janet
- Coordinate Biz issues
- Include PM tasks in the chart, with estimates and dates
- Collect information off-line, not in meetings
- Product Owner - responsible for vision/priorities:
- Roadmap: higher level timeframe
- Themes for each sprint: put this out to group before sprint planning
- Takes first pass through feature/bug queue before sprint planning to organize/prioritize in light of larger roadmap (business value)
- Primary artifact is the product backlog, prioritizing
- Team Manager:
- Resource management
- Performance
- Developers:
- Estimates of tasks
- Reporting exceptions in the scrum: task is taking longer than is expected, etc
- Manage own bug queue
- Do feature work, then bugs - we need to assign these in appropriate size chunks, so this is possible within a given sprint
- QA:
- Owns JIRA
- First pass at new bugs, assign:
- Component and developer
- Severity
- Priority
- Does this needed to be added to this round of changes? If so, raise it with team, in triage. If it seems really urgent, and a potentially large issue, might raise it in scrum as a red flag.
- Developers can pushback as needed, disagree with priority, severity, assignment
- Triage: mainly during QA phase, not during feature work; responsible for raising red flags, if there are issues that need to be addressed immediately/with greater urgency
- QA decides when final release is ok to go to prod
- Customer Support:
- First response
- Customer messaging
- Customer Advocate
- In communication with "Product Owner" about customer needs, priorities as they come up