JIRA, like every SaaS tool, has it's own nomenclature.
The basics include the following:
Term | Definition |
|---|---|
| Issues | Issues are the the core of JIRA. An issue is a piece of work. Issues are classified by type and have fields related to that. Examples include "Story", "Epic", "Task", "Bug", "Activity" |
| Projects | Projects are an organizational structure for issues. All issues must be created within a project. |
| Project Key | Every project has a name and a key. A key is a short-hand version of a project name. For example ESRFIS is a project key. Every issue that belongs in that project starts with the key followed by a number (ESRFIS-1,ESRFIS-2) |
| Fields | Fields are just fields that are placed on an issue. There are different types of fields such as checkboxes, open text, typehead, etc (think of filling out survey questions). |
| Custom Fields | Are fields we have created in order to track relevant information |
| System Fields | Are fields that come with JIRA and can be utilized for special purposes. |
| Filters and JQL (Jira Query Language) | Filters are saved searches. JIRA allows you to search using JQL (think of a simple SQL) and then save them as a filter. Filters are utilized in many parts of the system. |
| Dashboard | A "one stop shop" to display widgets and filters |
| Boards | A graphical display of a filter. A board allows you to visualize the work in a specific way (boards and backlogs). At the core, it is using a filter to decide what information to display |
| Tempo | A graphical display of time tracking. Tempo "My work" allows you to visualize how you log your time. Logging time is done on a given issue. |
Some important system fields:
Term | Definition |
|---|---|
| Components | Components are project-specific fields that can be used to categorize work such as components/modules of an application or workstreams within a project. An issue can have one or more components. Components can only be created by a project admin. |
| Due date | This field is used to track the planned completion of the task / milestone / epic. The PAH uses this date for volatility metrics. If the planned due date gets more refined, it is OK to change the due date. |
| Epic Link | This field is used to create a parent-child relationship between an Object and a task. A task can only belong to one Object (via the Epic Link). |
| Fix Version / Affected Version / Releases | This field is used to track the scope of work needed for a version to be marked done. In software, bugs are associated to affected versions, and stories and tasks are associated to fix versions. Fix Versions are also used as milestones in the system (Portfolio). |
| Issue link | This field is used to link issues or collab pages together. |
| Labels | Labels is a global field that is used to tag or categorize any type of work. An issue can have one more labels. This field isn't standardized across projects because anyone can create a label. |
| Original Estimate | This field is used to determine the effort (in hours) necessary in order to complete a piece of work. We encourage people to change the estimate field as data becomes available. |
| Parent Link (Portfolio only) | This field is used to create a parent-child relationship between an Object and Project Record. An object can only belong to one Project Record (via the Epic Link) |
| Resolution date | This is the actual completed date of the issue (or when it was closed). For project records, when we evaluated the project and agreed that the project is completed. |
| Time Spent / Logged Work | This field keeps track of how many hours a person(s) spends on an issue. |
| Target Start (portfolio only) | This field is used in portfolio to help with scheduling and visualization. |
| Target End (portfolio only) | This field is used in portfolio to help with scheduling and visualization |
Related articles
Filter by label
There are no items with the selected labels at this time.