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.