...
- P1: Fix by Next Major Release
- High value tickets mapped to goals
- Feature mapped to key customer need
- Crashes with high frequency of occurrence, or a cumbersome or non-existent work-around.
- Unmet requirement.
- Critical numeric error
- Unacceptably low quality in highly visible component.
- Critical loss of data.
- Failed input validation with critical consequence
- P2: Fix by Next Major Release if Time Permits
- Hard to duplicate crashes.
- Numeric issues regarding precision (agreement with truth is acceptable but would like it to be better).
- Numeric issues when near a singularity.
- Unclear/non-standard error messages in low visibility component.
Triaging Many Issues
There are times when many issues (hundreds) requiring triage. Below is our approach for triaging large quantities of issues in a timely manner.
- Organize tickets into two lists (each sorted by component)
- Bugs:
- Improvements/Tasks/Other:
- Make a First Pass
- If a ticket almost certainly needs to be addressed, mark it as P1 (i.e. we would slip a release if not completed)
- If there is almost no way we will do a ticket or it is simply too low value mark it as Someday or consider closing it as Won't Fix. (This helps keep backlog focused on the best ideas)
- If neither of the first two bullets above apply mark the ticket as P2 and label as below to help in second pass
- Polish (cleans up rough edges in existing product)
- Incremental improvement (small change to improve existing product)
- Bug (no need to label as this is handled in JIRA ticket type
- Make Second Pass
- Select a doable amount of highest value P2 issues in each area
- Polish
- Incremental
- Bug
- Move all others tickets to Someday
- Select a doable amount of highest value P2 issues in each area
Who Makes Decisions
The GMAT CCB is composed of senior project members (and soon customer representatives) that ensure a broad range of expertise on the board. Decisions are usually delegated to a subset of CCB members with expertise in the area regarding decision to be made.