Not all tickets are created equal. What follows is a conversation starter about how tickets should be prioritized by the core team:
type |
impact |
complexity |
patch included? |
core will typically |
typical urgency |
|---|---|---|---|---|---|
defect |
high |
low |
yes |
screen |
highest |
defect |
high |
low |
no |
vet, implement, screen |
high |
defect |
high |
high |
yes |
screen |
high |
defect |
high |
high |
no |
vet, implement, screen |
medium |
defect |
low |
low |
yes |
screen |
medium |
defect |
low |
low |
no |
vet |
medium |
defect |
low |
high |
yes |
screen |
medium |
defect |
low |
high |
no |
vet |
medium |
enhancement |
high |
low |
yes |
screen |
low |
enhancement |
high |
low |
no |
vet, implement, screen |
low |
enhancement |
high |
high |
yes |
screen |
low |
enhancement |
high |
high |
no |
vet, implement, screen |
low |
enhancement |
low |
low |
yes |
screen |
none |
enhancement |
low |
low |
no |
vet |
none |
enhancement |
low |
high |
yes |
screen |
none |
enhancement |
low |
high |
no |
vet |
none |
How this maps to the current JIRA workflow:
- defect and enhancement are ticket types
- impact is not tracked as a field
- complexity is not tracked as a field. Maybe I should use the work "subtlety" here. A thing is complex if it interplays with other things. Things are often more complex than they look!
- patch is tracked explicitly with the "patch" custom field, and implicitly by presence of attachments
- core team's actions are tracked by workflow and by the "Approval" custom field
- urgency is not directly tracked, but can be inferred from
- scheduled release (most useful!)
- priority (less useful)
Not captured in this picture:
- Core team will mark tickets as acceptance: incomplete when more information is needed.
