In the last section, you learned how to configure schemes in JIRA; we introduced screens, workflows, permissions, and even notifications.

In this section, you will learn about the following topics in detail:

• Screens
• Workflows
• Permissions
• Notifications

Let's flip over to the JIRA account and look at our project view, as follows:

1. Select the First Project, and, once you have the project loaded up, choose the settings for the project. Go over to the left-hand menu and select Settings.
2. In the previous section, you saw a little bit about screens, but now, you're going to learn about them more deeply. We use what's called a Scrum Issue Type Screen Scheme. We have a Scrum Default Screen Scheme that will cover the different work item issue types of Story, Epic, Task, and Sub-task; then, we have a Scrum Bug Screen Scheme that will cover the issue type Bug, as shown in the following screenshot:

Editing the default Scrum Issue Type Screen Scheme

3. Click on the edit icon on the right. We can then take a look at the default Issues screen, as follows:

Configuring the screen fields

4. This will give us control over all of the different fields that appear in an issue type. There may be some that we don't need to use, because our organization doesn't use them, or we don't find value in them. In that case, removing them from the interface will make things faster and/or cleaner. We can also drag and move the fields into different orders. Suppose that, for instance, we didn't want Components. We could easily just remove that by clicking on Remove. The Components would then no longer appear on any of our issue types, with the exception of bugs. We haven't configured the bug type yet.

5. At the bottom of the screen, we have the ability to select a field to add, as well; so, we can actually use that to add Components back, as follows:

Component/s addition on screen fields

We can just type components and add it back that way; we can drag it back up to right above Description, where we had it before.

That concludes our discussion of how to use screens in JIRA. Next, let's take a look at workflows.

In the options on the left-hand side of the screen, click on Workflows.

Adjustments to workflows allow us to see the different ways that a status can interact with another status, and how items can move from one status to the next:

1. Click on FP: Software Simplified Workflow Scheme, as shown in the following screenshot:

This will take us to the following screen, which gives us a flow diagram of the workflow:

Default Workflow example

2. Any type of work item can be moved to TO DO from all other states in the workflow. The same is true for DONE and IN PROGRESS. This is, by default, a highly accommodating workflow.
3. We can add a new status, such as CLOSED, by clicking on Add status.

4. Drag the new CLOSED status to the bottom, beneath IN PROGRESS; now, we have a new status, as follows:

Adding a CLOSED status to our Workflow

Then, we can create different actions that will happen when work items are moved in and out of this new closed status. For example, if our team is burning down hours as a metric instead of story points in our sprints, we may want to have the remaining hours item update itself to zero when the work item is moved into the CLOSED state. Another option would be to set the Resolution value of the work item behind the scenes, when we transition the item to closed. These are just a few examples of things that we can do in a workflow.

Next, we want to take a look at permissions, so we'll bring up the Permissions options for our default software scheme, which is what we're using for our Scrum project, as shown in the following screenshot:

Since we have access to everything, this isn't really critical right now, but if we'd had more people assigned to this project, then we might have wanted to assign who could do what, from both a project-permissions perspective and an issue-permissions perspective.

There is also a Notifications option under our First Project. You learned a little bit about this in the last section, but you'll learn more about it now:

Notifications can be tailored specific to a project

Suppose that you were the person that reported an issue, and, when that issue was created, as the reporter, you would be notified. You would also want the current assignee to be notified, since they have had something assigned to them. You'd also want any of the watchers of that item to be notified. Then, suppose that the issue gets updated. It may be that you (the reporter) don't want to be notified about that. Here, you can configure the notifications and set them up the way you would like.

You can execute the preceding scenario by clicking on Delete for the Reporter, under the Issue Updated section. This will take you to the following screen:

We can add and remove notifications

The reporter will now be notified when an item is created, but not when it's updated. The reporter is again notified when the item is assigned.