Search for issues by title, key, or description
Issue types categorize the nature and purpose of an issue. The system supports 9 different types to help organize and track work effectively.
Description: A defect or error in the system that causes incorrect or unexpected behavior. Bugs represent deviations from expected functionality.
Use cases:
Examples:
When to use: Use BUG when something that previously worked (or should work) is broken or not functioning correctly.
Description: A new capability or functionality to be added to the system. Stories expand what the system can do.
Use cases:
Examples:
When to use: Use STORY when adding completely new functionality that doesn't exist yet.
Description: A general work item that doesn't fit into other categories. Tasks are typically operational or administrative in nature.
Use cases:
Examples:
When to use: Use TASK when the work doesn't clearly fit into other categories, or when it's operational/maintenance work.
Description: An unplanned interruption or degradation of service. Incidents represent active problems affecting users or systems.
Use cases:
Examples:
When to use: Use INCIDENT for active production issues that need immediate attention.
Description: A post-release request coming from a user, not from a Product Owner or internal stakeholder. It is used to capture questions, usage issues, clarification needs, or support inquiries about an already released product, version, or feature. A SUPPORT_REQUEST is not delivery work. It exists outside the normal planning and implementation flow.
Use cases:
Examples:
When to use: Use SUPPORT_REQUEST when a user needs help or has a question, rather than reporting a bug.
Special Rules:
Description: Work related to creating, updating, or improving documentation. This includes all forms of documentation.
Use cases:
Examples:
When to use: Use DOCUMENTATION for any work focused on creating or improving documentation.
Description: A time-boxed investigation or research task. Spikes are exploratory work to understand a problem or solution before implementation.
Use cases:
Examples:
When to use: Use SPIKE when you need to investigate or research before you can properly estimate or implement a solution.
Description: A large body of work that can be broken down into smaller issues. Epics represent major initiatives or features that can span across multiple versions.
Use cases:
Examples:
When to use: Use EPIC for large initiatives that will be broken down into multiple STORY, TASK, or other type issues.
Special Rules:
Description: A smaller work item that is part of a larger issue. Subtasks help break down complex work into manageable pieces.
Use cases:
Examples:
When to use: Use SUB_TASK to break down a complex issue into smaller, trackable pieces.
Special Rules:
Some issue types have special rules that govern their behavior in the system. These rules are enforced to maintain data integrity and ensure consistent workflows.
Rule: EPIC issues cannot have a parent issue.
Reason: Epics represent top-level initiatives that organize work across multiple issues. Allowing epics to have parents would create unnecessary hierarchy complexity and could lead to circular dependencies.
Impact: When creating an EPIC issue, the parent issue field is not available or will be rejected if set. When attempting to set a parent issue on an existing EPIC, the operation will fail with an error.
Rule: EPIC issues cannot have a target version.
Reason: Epics represent large initiatives that can span across multiple versions. Child issues (STORY, TASK, etc.) within an epic have their own target versions, allowing the epic to track work across different releases. This design enables better planning and tracking of long-term initiatives.
Impact: When creating an EPIC issue, the target version field cannot be set. When attempting to set a target version on an existing EPIC, the operation will fail with an error. Existing EPICs with a target version can have it removed (set to null), but cannot set a new one.
Rule: SUPPORT_REQUEST issues are excluded from version effort estimates and can be assigned to released versions.
Reason: Support requests are typically reactive work that doesn\'t follow the same planning and estimation cycle as feature development. They need to be handled regardless of version status, and their effort shouldn\'t affect version planning metrics.
Impact: SUPPORT_REQUEST issues do not contribute to the total effort calculation when viewing version statistics. SUPPORT_REQUEST issues can be assigned to versions that have already been released (status: RELEASED). This allows support work to be tracked against the version where the issue was reported, even after release.
Rule: SUB_TASK issues must have a parent issue.
Reason: Subtasks represent work breakdown of a larger issue. Without a parent, a SUB_TASK loses its context and purpose. The parent-child relationship is essential for organizing work hierarchically and tracking progress.
Impact: When creating a SUB_TASK, a parent issue must be specified. When attempting to remove a parent from an existing SUB_TASK, the operation will fail with an error. The system will detect and report SUB_TASK issues without a parent as a problem.
Example: ✅ Valid: Create SUB_TASK "Create login form UI" with parent STORY "Add user authentication". ❌ Invalid: Create SUB_TASK "Create login form UI" without a parent issue.
Rule: SUB_TASK issues must be assigned to the same version as their parent issue.
Reason: Subtasks represent work breakdown of their parent issue. Keeping them in the same version ensures that all related work is delivered together and maintains version consistency.
Impact: When creating a SUB_TASK, if a parent issue is specified, the target version must match the parent\'s target version. When updating a SUB_TASK\'s target version, it must match the parent\'s target version. When updating a parent issue\'s target version, all SUB_TASK children should ideally be updated to match (this may be enforced or recommended by the system).
When creating a new issue, the default type is TASK.