| Ui tab |
|---|
|
trueBackground and ContextThis section is tailored to give you context on the "who, what, why" of JIRA. - JIRA, at the most basic level, is an issue and workflow tracking tool. It started in the industry focused on software (ie bugs) and later abstracted to all different types of issue tracking.
- It is commonly used as a robust project management tool in a lot of organizations.
- JIRA has also expanded to support other work areas:
- provide service-desk functionality (not enabled for us)
- agile/waterfall project management functionality (enabled for us)
- time tracking (enabled for us)
- Since JIRA has been around for 10+ years, there is a huge community and expansive documentation built out. A simple google can potentially find you answers that apply.
- JIRA is currently being managed by the Workplace Technology Services in IT Services at UCSD. They provide support and training around using the tool.
JIRA TerminologyJIRA, 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 | This field is used in portfolio to help with scheduling and visualization. | | Target End | This field is used in portfolio to help with scheduling and visualization |
UCSD TerminologyUCSD, like every company, has its own methodologies, processes, procedures, policies, and nomenclature. Below isn't an exhaustive list, but some useful ones to know: | UCSD | JIRA | Definition |
|---|
| Object | Epic | An Object is a deliverable that will be delivered as part of a project. Objects should be created with object types in mind. When creating one, an object type can be selected from a field. and categorized using These objects normally start with a noun. Some examples can be found here. | | Task | Task | A task is our to-do items and the actions we need to take to deliver an object. Tasks should be estimated effort and duration and be associated to an object on create. These normally start with a verb. Some examples can be found here. | | Activity | Activity | Activities are time tracking categories for operational work that may be reoccurring or necessary for a production service to keep up and running. Activities should also be associated to Objects and for reporting/categorizing purposes we also attach them to Component/s (a system field) | | Project | Project Record | A project record is a specific issue in the ITS Portfolio that provides metadata about any given project. It is used to help senior leadership understand how projects are progressing. This mostly applies to project managers, but included in here as informational. | | Task Phase | Phase | A field that only lives on tasks, that help define what part of the project the task relates to. |
Project RequirementsAs an UCSD ITS employee, below are a few activities you may be required to do inside JIRA:
UCSD Project Management Ontology
Managing a Project Record
Project Permissions
Managing Objects
Managing Tasks
Reports
JIRA Portfolio (optional)
|
| Ui tab |
|---|
|
trueBackground and Context
JIRA TerminologyJIRA, 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 | This field is used in portfolio to help with scheduling and visualization. | | Target End | This field is used in portfolio to help with scheduling and visualization |
UCSD TerminologyUCSD, like every company, has its own methodologies, processes, procedures, policies, and nomenclature. Below isn't an exhaustive list, but some useful ones to know: | UCSD | JIRA | Definition |
|---|
| Object | Epic | An Object is a deliverable that will be delivered as part of a project. Objects should be created with object types in mind. When creating one, an object type can be selected from a field. and categorized using These objects normally start with a noun. Some examples can be found here. | | Task | Task | A task is our to-do items and the actions we need to take to deliver an object. Tasks should be estimated effort and duration and be associated to an object on create. These normally start with a verb. Some examples can be found here. | | Activity | Activity | Activities are time tracking categories for operational work that may be reoccurring or necessary for a production service to keep up and running. Activities should also be associated to Objects and for reporting/categorizing purposes we also attach them to Component/s (a system field) | | Project | Project Record | A project record is a specific issue in the ITS Portfolio that provides metadata about any given project. It is used to help senior leadership understand how projects are progressing. This mostly applies to project managers, but included in here as informational. | | Task Phase | Phase | A field that only lives on tasks, that help define what part of the project the task relates to. |
Service Operational RequirementsAs an UCSD ITS employee, below are a few activities you may be required to do inside JIRA:
UCSD Service Operation Ontology
Managing a Project Record
Project Permissions
Managing Objects
Managing Activities
Managing Components
Reports
Managing Tasks (Optional)
|
|