Module 3

In this video, we'll discuss quick search and basic search,

will identify the ways to search in Jira, use quick search, and use basic search.

Play video starting at ::17 and follow transcript0:17

In Jira, there are many ways to view a projects progress, you can use project

boards, searching which we're going to discuss here, reports and dashboards.

Play video starting at ::30 and follow transcript0:30

There are a few ways to search in Jira, one is quick search,

which is a text search of issues, boards and projects.

Play video starting at ::40 and follow transcript0:40

Basic search which uses user interface elements to search for issues,

advanced search, which uses a text based search called JQL to search for issues.

Play video starting at ::54 and follow transcript0:54

Filters which are convenient saved searches, and

quick filters which limit the issues that are visible on a board.

Play video starting at :1:5 and follow transcript1:05

Searching is important because you can adapt your Jira experience to

your teams desired process.

A good search is usually going on behind the scenes of a specific view of your

project.

Play video starting at :1:19 and follow transcript1:19

Next we will discuss quick search, quick search is a global search

that can search for issues as well as other things such as projects.

On the left we see search in the cloud version of Jira and

on the right we see it in the server version.

The behavior is similar,

when you click on the quick search you will initially be shown recent items.

Play video starting at :1:43 and follow transcript1:43

As you begin typing in quick search, you will immediately begin to see results.

In this case, we've entered item and you can see that there are three issues

on Jira site, that have the word item in one of their text based fields.
Play video starting at :1:59 and follow transcript1:59

You can use the capitalized NOT keyword to exclude terms,

in this case we are excluding the number one which excludes the add item one issue.

You can use the capitalized OR keyword, to search for

issues containing one keyword or another.

In this case, we're searching for issues with either the word item or

sample in one of their text based fields.

Play video starting at :2:27 and follow transcript2:27

Next we will discuss basic search,

basic search is done with a row of user interface elements as shown here.

In this case, we're looking at all issues, so

none of the user interface elements are selective.

Play video starting at :2:43 and follow transcript2:43

We can limit the search,

for example here we are limiting the search to just issues in project, A.

Play video starting at :2:51 and follow transcript2:51

Basic search also includes a text box, so

you can search the fields of issues for certain values.

Play video starting at :3: and follow transcript3:00

If the field that you're interested in searching for is not shown,

you can select the more dropdown and search by other fields.

Play video starting at :3:10 and follow transcript3:10

You can search for other fields such as priority as we're doing here.

Play video starting at :3:17 and follow transcript3:17

In this case, we are searching for

issues that have been updated within the last three days.

You can see that basic search makes date based searches like this quite easy.

Play video starting at :3:29 and follow transcript3:29

Here's a review of what we've discussed, quick search

can search the text of issues, board names, project names, and filter names.

Basic search is a user friendly way to search for issues.

Play video starting at :3:43 and follow transcript3:43

Now it's time for you to work on the things discussed in this video,

separate hands-on instructions are provided for you.

LAB 1
In this video, we will discuss JQL.

We will start with a JQL overview.

In the previous video,

we explored basic search.

In this example, we are searching for all issues that

we have permission to view in project A.

On a basic search,

there is a switch to JQL link,

which allows you to switch to

the advanced mode of searching for issues.

Here is advanced or JQL search,

Jira will automatically populate the textbox,

with a text-based equivalent

for the current basic search.

You can click the switch to

basic link to change back to the basic search.

That text that we saw in

the advanced issue search is called

Jira query language or JQL.

JQL uses a structured query language like syntax.

Structured query language is commonly

called SQL or Sequel.

This is used to search databases.

JQL is used to search issues only.

This is why the JQL string can be so simple.

You don't have to enter something like from

issue in the query because that is implied.

We have seen that the basic search contains

user-friendly interface elements to perform the search.

We have also seen that the queries

can be quite complex by

selecting from multiple elements

or adding text-based searching.

Advanced search uses JQL

and allows for more powerful searches because

it is not limited to the capabilities of

the user interface elements of basic search.

Also, if you are automating anything related to Jira,

you would use JQL because

automation relies on text-based scripts.

Whether you are using basic or advanced search,

the JQL related to

the search is always there behind the scenes.

The easiest way to write

the JQL query is not to write it at all.

You can let Jira write it for you.

Here we are in basic search and

select Project A from the dropdown.

We can then click on the Advanced

link" to enter the advanced search.

The search results don't change at all,

but the query is displayed instead

of the basic search user interface.

That query displays all of the issues

with a project key of PROJ.

The results are ordered by

the date that the issue was created.

JQL queries can fundamentally do

two things and we see both of

them in the query that was just created.

They can select a subset of issues,

as we see in the first part of the query.

We are selecting only issues in which

the project field has a value of PROJ.

They can sort the results using an ORDER By clause.

We are ordering the results

by the date that they were created.

Next, we will discuss autocomplete.

We have the option of creating a JQL query from scratch.

Let's create a query that

searches for the issues in our project.

Project is a field name in a Jira issue,

and each issue is assigned to a single project.

In the Advanced Search textbox,

we can begin typing pr and

Jira will help us with autocomplete suggestions.

Autocomplete will show up to 15 matches,

this makes writing JQL much

easier and helps avoid mistakes.

In this case, we select

the project field as the start to the query.

Notice that there is a syntax help option

at the bottom of the list,

this will point you to

the documentation for advanced search.

When we have entered project in

the search box and hit the spacebar,

Jira provides a list of

choices of what should be next in the query.

This list contains what are called operators,

and since we are looking for

issues in our particular project,

we select the equals operator.

When you press the spacebar

after entering the equals operator,

Jira again provides you with a list of choices.

We can see that this Jira account has

three projects that we have permission to see,

and we can select a project name to view these issues.

When we complete the query and click "Enter",

the search is performed.

At this point, if we click on the basic link,

we can see that project A

is selected in the dropdown list.

This is equivalent to the JQL that we just created.

If we click on the updated column in the search results,

the results are sorted and we can see that

our query has been updated with an ORDER By clause.

This is very helpful in creating JQL queries.

You can create a search in basic search,

change the output to

be sorted the way that you would like,

and then copy the query that Jira has created.

You usually don't have to create queries from scratch.

In the previous example,

we knew that we were searching for the project field.

If you are unsure of which field to search for,

or to get more information related to the field,

such as supported operators and functions,

search the web for the advanced

searching-fields reference documentation from Atlassian.

Next we will discuss Order By.

The simplest JQL is an empty string as shown here.

This means that we are not being selective about

which issues that we see, so we see them all.

You can see that there are 29 issues

in this Jira account,

assuming that the current user has

permission to see all of the issues.

We don't specify how we

would like the results to be ordered,

so Jira picks the default ordering.

It looks like the default ordering is by

the issue key in a descending order.

Order By in a JQL query is

used to specify the order of the results.

In this simple case of an empty string as a query,

as we see on the left,

all of the issues are displayed in the default order.

We guessed that the default sorting is

by issue key in a descending order.

On the right, we verify that guess by

specifically adding an order by clause to the query.

You can see that if we specify Order By key descending,

we get the same results as we did with the empty query.

The only real difference is that on the right,

you see a descending arrow on the key column header.

If you click on the All Issues link under Filters,

you can see that the query is simply an Order By clause.

The results are ordered by the date

and time that the issue was created,

starting with the most recently created issue.

You can also see that the created column header

has a descending arrow.

Clicking on any column header will

change the Order By clause in the query.

You can add multiple field names to the Order By

clause by separating them with commas.

The first field name is the primary sorting field,

and any other fields take effect only if

the prior field had

multiple values that were exactly the same.

In this example, we are sorting primarily by

the summary field because it

is first in the Order By clause,

and because you can see that

the summary column has the sorting arrow.

We have multiple issues with the exact same summary,

so the secondary field of the issue

key is used to sort those matches.

As you click on multiple columns in the search results,

you will notice that more fields are

added to the Order By clause.

The first field is by far the most important one.

Next, we will discuss Functions.

Play video starting at :7:49 and follow transcript7:49

You usually only want to return

a subset of issues from a search.

An issue selection clause is used to limit

or filter the issues that are returned in the results.

The basic structure of the clause is

a field name followed by an operator,

followed by a field value.

We have seen an example where we are selecting all issues

that have a project field value of project A.

Instead of directly providing

a field value in the issue selection clause,

you can provide a function.

A function is a small program that Jira

calls before the query is executed.

The result of calling the function

is then substituted in the query.

As an example, this clause will search for issues that

have been assigned to the currently logged in JIRA user.

A big advantage of using functions

is that you are not hard coding information.

This same query can be used

by all users to view their issues.

Play video starting at :8:45 and follow transcript8:45

The Jira advanced searching functions are

documented so that you can use

them if and when you need them.

Do a search for advanced searching functions

reference to find it on Atlassian's website.

You can then find the details

related to any functions that interest you.

Here's a list of the advanced search functions

that are related to time and date.

There are functions that specify the start of

a time period and the end of a time period.

The now function represents the current time.

The current login function results in

the time that the current user logged into the session,

and the last login function results in the time

that the current user logged into the previous session.

As an example, this query will

find issues created since the start of today.

If the field is related to dates,

you can add what's called a time unit qualifier

to specify relative dates as field values.

This is a specially formatted string that Jira will

replace with an actual date value

before running the query.

In this example, we are searching for

issues created in the last two days.

The time unit qualifier is handy because it is

simple and the query doesn't have a hard-coded date.

This line shows the syntax that can

be used to specify time units.

It starts with a plus sign,

a vertical bar, and a minus sign in parentheses.

The parentheses mean that what is inside is optional.

The vertical bar means or.

If you add a minus sign to the string,

you are searching back in time.

Using the plus sign or leaving off the sign

altogether means that you are searching forward in time.

You can see that this query uses the minus sign.

So this query is searching for issues

that were created two days ago or later.

The nn in the string represents numeric digits.

In this string, the numeric digit is two.

Following the numeric digits

is the optional time period unit.

You can specify y for year,

capital M for month,

w for week, d for day,

h for hour, and lowercase m for a minute.

In this case we specify d. So this query

is searching for issues created within the last two days.

We could change that d to a w, for example,

to search for issues that were

created in the past two weeks.

If you leave off the units,

Jira will assume a logical default unit,

which depends on the circumstances.

You can also use time unit qualifiers

as arguments to a function.

An argument is a value that is

passed to functions to change its behavior.

If the trailing parenthesis of a function call are empty,

you are not passing any arguments

and the function is called with its default behavior.

In this example, we are adding

an argument to change the function so that

we are searching for issues created

since the start of day two days ago.

If today is Wednesday,

this would be searching for

issues created Monday or later.

Here's an example of finding issues

created since the 15th of this month,

assuming we are currently in

the second half of the month.

Notice that the function is related to months,

but we are passing an argument related to days.

The time periods do not need the match.

Next, we will discuss operators.

An operator is placed
between the field name and the value.

In this example, the operator is the equal sign.

You can use autocomplete to see

which operators that you can

use for a specific field name.

In this example, we have entered

the "project" field name and then pressed the space bar.

Autocomplete provides a list

of choices for the operators.

In this example, we have entered

the "summary" field name and then pressed the space bar.

Notice that Jira provides

a different list of operators for the "summary" field.

For example, the "project" field

accepts the equals sign as an operator,

and the "summary" field accepts

the contains operator which is represented by a tilde.

Jira's autocomplete provides the acceptable operators

based on the expected type of field value.

The "project" field expects a project name and

the summary field expects a free form of text.

The advanced searching operators reference

documents the details related to operators.

We will briefly go over operators in this video,

but this is mostly to provide you awareness of

what is possible with operators in queries.

The operators reference is very

helpful as you are writing queries.

The equals operator will find issues where

the field value exactly matches the value in the query.

This query will find all issues in "projectA."

The not equals operator represented by

an exclamation point before the equal sign,

finds issues where the field value does

not exactly match the value in the query.

This query finds all issues that are

not in the "projectA" project.

Some fields allow the greater than,

greater than or equal,

less than and less than or equals operators.

For example, these are commonly used along with

fields that expect values of dates.

This query finds issues created today.

This query uses the greater than or equals operator

to find issues with three or more "Story Points."

Notice that we have to surround the field name

in quotes because it contains a space.

This query finds issues created more than a week ago.

This query finds issues with

three or less "Story Points."

The "in" and "not in" operators are used with

a comma separated list of values in the query.

This query finds issues that are either

in "projectA" or "projectB."

Notice that there are parentheses around the set of

values and the values are separated using commas.

This query finds issues that are

not in "projectA" or "projectB."

The "is" and "is

not" operators are very limited in what they do.

They are used to determine if

a value has been set for a field.

These operators can only be followed by

one of two values, empty or null.

Both values are keywords in JQL.

They mean the same thing.

In this example, we find issues that have no assignee.

We do this first using the "is" operator,

which is equivalent to the equals operator.

In this example, we find issues that

haven't assignee using the "is not" operator.

This query is equivalent to a query

that uses the "not equals" operator.

The "contains" and "does not contain"

operators are used with text fields only.

Text fields include summary, description,

environment, comments, and any custom text fields.

In this example, our field is

"summary," and since it is a text field,

the "contains" and "does not

contain" operators are offered as options.

This query finds issues in which

the "summary" field has a value of "item 1."

We put quotes around the value because values

with spaces must be surrounded by quotes.

This query finds all issues where there's

summary does not contain the word "item."

Quotes are not required because this is

a single string of simple text.

You can perform a search that

is similar to the global search

using a special name of text and the "contains" operator.

You can see that you can use

the same text query syntax that

we discussed for quick search earlier.

Note that the capital not

inside the string is case sensitive.

A lowercase "not" is

a reserved word and is ignored in the search.

The keywords in these text fields

searches are an exception to

the general rule that Jira searches are case insensitive.

The "was" and "was not" operators are used

to find issues that previously had a value.

Since Jira keeps a historic record of events and values,

that history can be searched using these operators.

In this example, we find issues

where the current user has been assigned.

In this example, we find issues that have

never had a status of "In Progress."

The was in and was not in operators are

similar to the was and was not operators,

but applied to a set of

values rather than a single value.

This query finds issues that had one of two statuses.

Either "Selected for Development" or "In Progress".

This query uses the was not in operator to

find issues that have never

had one of those two statuses.

The operators with the word "was" in them

can have a predicate appended to the clause.

Predicates are used to

narrow the search results from the clause.

Here is the list of predicates for these operators.

The AFTER, BEFORE, DURING, and ON,

predicates are used to limit the date range of the query.

The BY predicate is used to

specify the user performing the change.

This example finds all issues that were moved to

the Done status by the current user in the past month.

Notice that predicates can be combined,

as we see here with the BY and AFTER predicates.

The final operator that we will

discuss is the changed operator.

This is used to find issues that

have a field value that has changed.

For example, this query finds issues

whose assignee has changed since the issue was created.

The changed operator also has predicates that can

be added in order to narrow the returned issues.

In addition to the predicates that we saw

related to the was operators,

the changed operator adds FROM and TO predicates.

This example finds issues whose status changed from

"Done" to "In Progress" at some point in their history.

Next, we will discuss Boolean operators.

Boolean operators are used to either

combine or negate clauses.

The AND and OR Boolean operators

are used to combine multiple clauses,

allowing you to refine your search.

For example, this query finds all issues assigned

to the current user with the status of "In Progress".

This query finds all issues with the status of

"Selected for Development" or "In Progress".

This query is equivalent to using the IN operator.

The NOT operator is used to negate one or more clauses.

For example, this query finds

issues that do not have a status of Backlog.

This is equivalent to using the NOT equals operator.

In this example, we find unresolved issues in

all projects except for the SampleA project.

Notice that we are combining

AND and NOT Boolean operators.

You could do the same with OR and NOT Boolean operators.

If your query has multiple Boolean operators,

use parentheses to set

the operator precedence and improve query readability.

In this example, we have added parentheses,

so the OR Boolean operator is evaluated first.

The result is then ended with the first clause.

This query searches for all issues with the status

of "Selected for Development" or "In Progress",

with the summary containing the text item.

You can see that this results in eight issues.

If we remove the parentheses,

the AND Boolean operator is evaluated first.

In this example, we are searching for issues

containing the text item with the status

of "Selected for Development" or any

issue that has the status of "In Progress".

You can see that the results include

one more issue than the previous search,

because this query will include

any issues with the status of "In Progress",

even if the word "item" is not in the summary.

If your query combines the use of

AND and OR Boolean operators,

there are two precedence rules.

Parentheses take precedence, meaning that what is

inside of parentheses is evaluated first.

The AND operator normally has precedence over OR.

This means that if there are

no parentheses to set precedence,

the AND operators are evaluated first from left to right.

This is analogous to math,

where multiplication has precedence over addition,

unless parentheses changed the precedence.

Here's an example.

This query contains an OR

as well as an AND Boolean operator.

Since there are no parentheses

used to change the precedence,

the AND is evaluated first

because AND has precedence over OR.

This query is equivalent to the previous query.

Putting parenthesis around the AND operator

means that AND is evaluated first,

but it already was evaluated first in this query,

so the queries are equivalent.

A general tip is to use parenthesis and queries with

mixed operators to keep things simple and unambiguous.

Here's a review of what we've discussed in this video.

A JQL query is behind all basic and advanced searches.

Leverage basic queries and autocomplete

to simplify creating JQL queries.

JQL queries may select subsets of

issues and/or order query results.

Functions can be used to avoid

hard-coding values in a clause.

Time unit qualifiers can be

used with date-related fields.

Allowable operators depend on the type of field value.

Use operator autocomplete to simplify writing clauses.

Boolean operators are used to combine or negate clauses.

Play video starting at :22:50 and follow transcript22:50

Now it's time for you to work on some of

the things that we've discussed in this video.

Separate hands-on instructions are provided for you.

LAB2
a
In this video, we will discuss filters.

We will create filters, describe board filters, and use quick filters.

Play video starting at ::12 and follow transcript0:12

You can see here on the left that there's a list of tabs known as filters.

Filters are saved searches to allow you to quickly execute a search.

In this case, we've selected the my open issues filter.

You can create your own filter by executing a search and

then clicking Save as.

Play video starting at ::34 and follow transcript0:34

You will then be asked to name your filter.

Here, we're calling it My in progress.

Play video starting at ::41 and follow transcript0:41

Once you have created the filter,

it will show in the sidebar under the starred category.

You can click on the Details link to the right of the filter name to view and

edit the details of the filter.

Play video starting at ::54 and follow transcript0:54

In the filter details,

you can click on the Edit permissions link to show the dialogue in the upper right.

Here, you can specify who has access to the filter.

In this case, we're keeping it private.

If you click on the New subscription link,

you'll see the dialogue in the lower right.

Subscriptions email recipients to query results at a rate specified

in the subscription.

The recipients can be specific users or members of Jira groups.

In this case, this is a personal subscription and

the query results will be mailed once per day.

You can also click on View all filters in the sidebar to see your filter.

You can click on the more icon to the right of the filter to change metadata
related to the filter.

Play video starting at :1:41 and follow transcript1:41

You can select your filter and change the search.

You will then see that your filter has been edited and

you can click Save to save the changes.

Next, we will discuss board filters.

Play video starting at :1:57 and follow transcript1:57

Every board has a filter that defines the issues shown on the board.

In board settings, you can edit the board's filter,

allowing you to change which issues are shown on the board.

If you create a board, you must assign it to a new or existing filter.

Here, you can see the query used behind the scenes for a board.

It's selecting all issues with the project key of PRJCT and

ordering them by their rank.

Play video starting at :2:28 and follow transcript2:28

A board filter can be used to show issues from multiple projects on a single board.

On the left, under Filter Query, you can see that the JQL

includes issues from projects with the key of PRJCT or PRJ.

When we view the board as shown on the right,

we can see that there's issues from multiple projects.

Play video starting at :2:51 and follow transcript2:51

Next, we will discuss quick filters.

Play video starting at :2:56 and follow transcript2:56

Quick filters are a way to further filter issues displayed on a board.

By default all of the issues that match the board filter are displayed.

Here, you can see that there are six quick filters.

If you click on a user's icon, you will see only issues assigned to them.

You could also click on the Only My Issues or recently updated quick filters.

Notice that the board also contains a search box, so

you can use a text based search to further limit the issues shown on the board.

Play video starting at :3:31 and follow transcript3:31

Quick filters can be used to refine reports.

Here, for a cumulative flow diagram, we've selected the Refine Report drop down.

You can see that you can select a quick filter to further refine the report.

In this case, we will see the older issues that are not complete.

Here's a review of what we've discussed in this video.

Filters are saved searches that can be exposed through user interface elements.

Every board has a filter that defines the issues shown on the board.

Play video starting at :4:9 and follow transcript4:09

Quick filters are saved searches that are used to further limit the issues

displayed on a board or in reports.

Play video starting at :4:18 and follow transcript4:18

>> Now, it's time for you to work on the things discussed in this video.

Separate hands-on instructions are provided for you.

LAB 3
In this video, we will discuss issue types.

Play video starting at ::6 and follow transcript0:06

We will start with an overview of issue types.

Play video starting at ::10 and follow transcript0:10

In Jira, an issue is a generic name for a unit of work.

And your projects, they're usually different types of units of work.

The issue type field is used to differentiate these.

When you create an issue, you can choose the issue type.

You can also change the issue type after creating it.

Notice that each type has an associated icon to help easily identify

the issue type.

Play video starting at ::37 and follow transcript0:37

A story is a requirement from the users perspective.

Play video starting at ::41 and follow transcript0:41

A task is a work item that needs to be done by the team, but

is not directly tied to a user requirement.

An example might be upgrading the version of a product used by the team.

Play video starting at ::54 and follow transcript0:54

A bug is a flaw that needs to be fixed in the product.

It can be tracked with its own issue type to differentiate this work from other

types of work.

Play video starting at :1:4 and follow transcript1:04

An epic is a big issue that can contain other issues.

Play video starting at :1:9 and follow transcript1:09

A subtask is a part of another issue.

It is used to break an issue down into specific pieces of work.

When creating an issue, subtask is not shown in the issue type dropdown

because subtasks must have a parent issue.

They cannot be created independently.

Play video starting at :1:29 and follow transcript1:29

In addition to these out of the box issue types, you can create custom issue types.
This provides your team the flexibility to work the way that they want to work.

Play video starting at :1:38 and follow transcript1:38

How the team actually defines with each issue type means is entirely up to them.

Also, a different projects can use different issue types.

Play video starting at :1:49 and follow transcript1:49

There are several reasons to use issue types with your projects.

Play video starting at :1:54 and follow transcript1:54

They support different types of work items.

A team usually doesn't have only one type of work and

issue types allow the team to differentiate those.

Play video starting at :2:6 and follow transcript2:06

Each type can have different fields, screens, and workflows.

For example, you might want bugs to appear at the top of the project sport.

Play video starting at :2:15 and follow transcript2:15

You can also report on issue type separately.

For example,

because the issues of the project have been categorized by issue type,

you can easily create a report with the number of bugs fixed in the previous week.

We will discuss each of these more later.

Play video starting at :2:33 and follow transcript2:33

Next, we will discuss subtasks.

Play video starting at :2:36 and follow transcript2:36

Subtasks are an issue type that must have a parent type.

To create a subtask, you click on the create subtask icon for the parent issue.

Play video starting at :2:47 and follow transcript2:47

Subtasks allow an issue to be broken down into individually manageable tasks that

can be assigned to different team members.

Subtask can be more technical than the parent issue.

For example, if the parent issue is a story, the story will be written in

nontechnical language that all team members and stakeholders understand.

But the subtasks can be written for the technical person implementing the subtask.
Play video starting at :3:14 and follow transcript3:14

Subtasks have their own issue keys and fields.

Here is the story with two subtasks.

Each subtask has its own issue key and summary field value.

Play video starting at :3:26 and follow transcript3:26

The subtasks have independent workflow statuses and

move through project boards in dependently.

Play video starting at :3:33 and follow transcript3:33

Since subtasks have their own issue keys and

fields that can be converted to other types of issues.

To convert a subtask to another type of issue,

view its details, then click on the more icon and select Convert to issue.

Play video starting at :3:49 and follow transcript3:49

Converting a subtask to an issue involves a few steps.

The first is to select the new issue type.

Here we are converting a subtask to a task.

You are then prompted to optionally change field values for the issue.

Play video starting at :4:5 and follow transcript4:05

You can also convert other issue types to subtasks.

Click on the more icon for an issue, an select Convert to subtask.

Play video starting at :4:15 and follow transcript4:15

When converting an issue to a subtask, you must select the parent issue.

You will then be prompted to update the subtasks field if desired.

Play video starting at :4:26 and follow transcript4:26

Next, we will discuss editing issue types.

Play video starting at :4:31 and follow transcript4:31

Creating and modifying issue types is done for

the project by navigating to the project and then selecting project settings.

This allows you to administer the project.

Play video starting at :4:44 and follow transcript4:44

After navigating to the settings for the project,

click on issue types to view the issue types for the project.

You can see that this project has five issue types.

These are the default types for Kanban projects.

Play video starting at :4:58 and follow transcript4:58

The issue types for

Project are organized into something called an Issue Type Scheme.

Schemes are commonly used behind the scenes in Jira to organize a collection of

related things.

The Issue Type Scheme name includes the project key.

You can change this issue type scheme without affecting other projects unless

some other project decided to use your scheme.

Notice that each issue type can have a unique workflow associated with it.

All of the issue types use the same workflow, so

they will all go through the same status is.

Play video starting at :5:33 and follow transcript5:33

Each issue type can have unique fields allowing you to customize an issue by

issue type.

In this case, all of the issue types use the same field configuration,

so the field names are the same for all issue types.

Play video starting at :5:46 and follow transcript5:46

Each issue type can have unique screens.

The screen is a user interface element used to show fields to users in

a context appropriate way.

For each issue type a screen scheme is used.

Screen schemes are collections of screens.

In this case, all of the issue types use the con bon default screen scheme with

the exception of bugs.

The screens for bugs are slightly different than other screens.

To show bug related fields that would not normally apply to the other issue types.

Play video starting at :6:19 and follow transcript6:19

To change something related to your issue type scheme, click on actions.

You can see that you have two basic options.

You can edit this issue type scheme or you can reuse an existing scheme.

As an example, we will click on edit issue types so

that we can make a minor change to the existing issue type scheme.

Before we click on this, notice that we are still in the settings for the project.

Play video starting at :6:45 and follow transcript6:45

Here's the modify issue type scheme screen.

Notice that we have changed from the project settings context to the settings

for the entire Jira application.

This is because issue type schemes can be shared by more than one project.

Jira has navigated you to the issue type scheme section and

selected the issue type scheme for your current project.

Play video starting at :7:6 and follow transcript7:06

On this screen here you can modify the scheme name.

Here you can add a description.

Here you can change the default issue type that is selected when you create an issue.

When we first created issues earlier in the course, they were stories.

Because of this setting.

Here's the list of issue types for

the current scheme in the order that they would appear in a drop down list.

You can drag and drop inside of this list to change this order if you

don't want to use one of the issue types in your project,

you can drag it from the list on the left to the list on the right.

The list on the right contains any issue types that are defined in your Jira

account that are not used by your project.

For example, a custom issue types from other projects would appear here.

If you want to add an issue type to your project, click the add issue type button.

Play video starting at :7:59 and follow transcript7:59

Here's the screen that appears when we click the add issue type button.

You can create any issue type that makes sense to your team.

Here we have created an issue type named Small.

This might be created because the team has a policy that all work must

be tracked in Jira.

Even items that take a small amount of time to complete.

This differentiates this type of work from bigger issues,

allowing you to report on them only if necessary.

For example, you can exclude these from a cumulative flow diagram.

When adding an issue type,

you have the option of creating it as a standalone issue type or a sub-task.

If you select sub-task, this issue type must have apparent issue.

You could not create them in dependently.

Play video starting at :8:46 and follow transcript8:46

Once we have added an issue type, it appears in the list of issue types for

the project.

Play video starting at :8:52 and follow transcript8:52

We could change the order of appearance by dragging it to

a different location in the list.

When you are happy with the changes to the issue type scheme, click save.

Play video starting at :9:3 and follow transcript9:03

After modifying the issue type scheme to your brings us back to the settings

context for our project.

Our issue type scheme now shows the added issue type.

Notice that our issue type has been given an icon.

It also has been assigned the same workflow, field configuration and

screen as most of the other issue types in the project.

Any of these can be changed.

Play video starting at :9:28 and follow transcript9:28

To change an issue type, navigate to the Jira application settings and

select issues.

Play video starting at :9:34 and follow transcript9:34

Then issue types.

Here we can see our new issue type with options to edit, delete or
translate the issue type to a different language.

Play video starting at :9:45 and follow transcript9:45

Now when we create a new issue in our project, we can select our new issue type.

Play video starting at :9:52 and follow transcript9:52

Next we will discuss using issue types in queries and swim lanes.

Play video starting at :9:59 and follow transcript9:59

Basics.

Search has a type dropdown that contains the issue types.

In your dear application.

Play video starting at :10:5 and follow transcript10:05

You can see that this contains the default issue types as well as any custom types.

We can see our new small issue type in the drop down.

Play video starting at :10:15 and follow transcript10:15

Here we have searched for all issues with the small issue type.

If you click on the advanced search you will see that this issue type field is

searched in the query.

Play video starting at :10:26 and follow transcript10:26

A swimlane allows you to horizontally organized issues with certain

characteristics on a board.

For example, you could have a special role for expedited issues.

Here we have created a swim lane for our small issue type.

So that the small tasks are separated from normal issues on the board.

Play video starting at :10:46 and follow transcript10:46

Swim lanes are configured using the swimlanes tab under board settings.

We have chosen to base our swimlane on queries and

have added a swimlane named small tasks.

The JQL for the swimlane can select from any subset of the boards issues,

and this query selects for issues with an issue type of small.

Any issues that are returned by this query are placed in a separate row on the board.

Every other issue that the boards filter matches will be shown under the everything

else heading.
We can drag and drop the order of the Rose here if we would like to

move the small tasks wrote to the bottom of the board.

Here again is the board with the swim Lane.

You can see that our query selected one issue for the small tasks swimlane.

And the rest of the issues that match the boards filter are shown under

the everything else heading.

Play video starting at :11:39 and follow transcript11:39

Here's a review of what we've discussed in this video.

Each issue has an issue type field that identifies the type of work of the issue.

Play video starting at :11:49 and follow transcript11:49

Each issue type can have unique fields, screens and workflows.

So tests are issue types that must have a parent issue.

Play video starting at :11:59 and follow transcript11:59

A collection of issue types used by projects is called an issue type scheme.

Jira allows you to customize issue types for each project.

Play video starting at :12:10 and follow transcript12:10

Swim lanes can be configured on boards using any field including issue type.

Now it's time for

you to work on some of the things that we've discussed in this video.

Separate hands-on instructions are provided for you.

LAB 4
LAB 5
In this video we will discuss configuring issues.

We will start by discussing labels.

Labels are a field used to help categorize and search for

issues in any way that makes sense to the team.

You can have multiple labels per issue.

This issue has two labels, refactor and database.

Play video starting at ::26 and follow transcript0:26

Labels can be added as you create an issue or can be added to existing issues.

Jira will suggest existing labels as you type.

Play video starting at ::36 and follow transcript0:36

In this example, in the create issue screen,

we type an r and we see that we can select the refactor label.

We could also type a new name and the label will be created.

Play video starting at ::50 and follow transcript0:50

You can click on a label in an issue and

Jira will take you to a search page containing all issues with this label.

Here's a search for issues with the label of refactor.

You can see that the field name is labels.

You can add this field to any search that you do in Jira.

Play video starting at :1:12 and follow transcript1:12

Let's say that we are not interested in database related issues right now.

Here we are searching for issues with the label of refactor, but

not a label with database.

Play video starting at :1:25 and follow transcript1:25

Next we will discuss configuring screens.

Screens display fields of an issue and can differ depending on the context.

Here is an example of a screen showing an issues details.

Jira project administrators and

Jira administrators can configure the layout of these screens for the project.

Let's make a simple configuration change.

You can see that Story Points is a field that is displayed under the Show more

fields drop-down.

Let's configure this screen so that Story Points is shown above that drop-down.

We can start by clicking the Configure icon in the lower right or

by selecting Configure from the More menu.

Clicking on Configure when viewing an issue takes you to the Issue layout tab

under Project settings.

Here you can rearrange, show and hide fields shown on the screens.

The reason that the Story Points field wasn't shown above the drop-down

on the issue detail screen is because it is listed here under Hide when empty.

This means that the Story Points field will appear under

the Show more fields drop-down if a value hasn't been set for the field.

To make the Story Points field always visible,

we can drag it above the Hide when empty section and save our changes.

Now when any member of the project views and issues details,

they can see the Story Points field above the Show more fields drop-down.

The simple configuration that we made is working as expected.

Next we will discuss custom fields.

Play video starting at :3:3 and follow transcript3:03

Jira comes with a lot of default fields for an issue.

In general, you want to try to keep things simple and

use those default fields whenever possible.

You can add custom fields to issues to answer specific needs of your team.

We will create a field called Acceptance Criteria.

Acceptance Criteria are often used with stories.

For example, a product owner would write a list of criteria that must be true for

the story to be accepted as done.

We could add this list right in the description of the story, but

some teams may want to create a specific field for this.

To add a custom field to classic projects, you must be a Jira administrator.

You can click on the gear icon in the upper right, and under Jira settings,

select Issues.

You can then click on the Custom fields tab as shown here.

Play video starting at :3:56 and follow transcript3:56

You then click on the Create custom field button.

You are then presented with the Select a Field Type dialogue.

Each field has an associated type depending on what you

want to do with the field.

You can see that there are many standard types to choose from.

You can also click on the Advanced tab to view more types.

Since we want the product owner to create a free form list of acceptance criteria,

we will select the multi-line text field as the field type.

You can then add a name and description for this field.

Here we have entered a description of a list of user-centered tests that must pass
for the story to be considered done.

Play video starting at :4:39 and follow transcript4:39

You then associate your custom field with the screens for your project.

If we do this, this field will not show up on screens for other projects.

Play video starting at :4:49 and follow transcript4:49

You then see your custom field and

can see that it is associated with one screen in your project.

Now when you create or update issues in your project,

you can add values to your custom field as we see here.

Play video starting at :5:4 and follow transcript5:04

You may have noticed that some field values are required.

For example, when you create an issue, the project field is required.

This is because all issues must belong to one project.

Play video starting at :5:17 and follow transcript5:17

For our custom acceptance criteria field, we can set the field to be required by

navigating to the Jira settings, then Issues, then Field configurations.

In the default field configuration, we can see our Acceptance Criteria

field along with the list of screens that contain the field.

You can see that the default issue screen for

our project is the only screen that it will appear on.

Under Actions, we could make our field required by clicking the Required link.

There are also other available actions related to the field.

For example, we could add it to more screens using the Screens link.

Play video starting at :5:56 and follow transcript5:56

Here's a review of what we've discussed in this video.

Labels are used to categorize and search for issues.

Screens display context appropriate fields for an issue.

Jira project administrators and Jira administrators can configure screens.

Jira administrators can create custom fields and add them to screens.

Now it's time for

you to work on some of the things that we've discussed in this video.
Separate hands-on instructions are provided for you.

LAB 6
LAB 7