Effective Management of Jira Projects on the Cloud

In this module, you’ll get an overview of managing projects in Jira.

You’ll learn the basic responsibilities of administering Jira projects

Explain the overall goal of Jira project administration.

Review the basic components of a Jira project.

Explain the difference between Company-managed and Team-managed projects, And learn how to create a Jira Software project.

Let’s begin by exploring what we mean by Jira project administration.

This course is designed for anyone responsible for managing and maintaining the health of one or more Jira projects. Depending on the size and structure of your organization, this person might have the formal title of scrum master, project lead, product owner, or project administrator, or the role might be less formally defined, or a responsibility shared among multiple team members. Ultimately, it’s the person or persons who make sure Jira compliments their team’s work process.

Within Jira, there are several types of users, or roles, that have specific capabilities within the application.

A Site administrator manages users – they create user accounts, assign users to groups, and grant application access. They also access billing information for the site.

A Jira administrator configures the Jira instance for all users. They in general know the most about the technical capabilities of Jira and can set policies for the entire company to use with their Jira projects. The changes that they can make can affect multiple projects, so they must be very knowledgeable of Jira.

A Jira project administrator can perform limited configurations on a specific Jira project so it matches the team’s desired process. Jira project administrators work closely with the agile team to understand their work process, and must work with the Jira administrator to configure their Jira project..

A team member uses Jira to work on projects.

In general, a company has a few Jira administrators, more Jira project administrators, and even more team members.

This course is aimed at Project administrators, but in some organizations, this role is fulfilled by the Jira administrator, as well.

Administering Jira projects typically involves some combination of the following responsibilities:

• Working with the team to gather their requirements and understand their work process

• Working with Jira administrators to implement projects, configurations, and customizations

• Granting user access through role membership

• Managing boards, sprints, and backlogs

• Running reports and creating dashboards

• And monitoring the overall health of their Jira projects

We will be discussing these topics throughout the course.

Projects in Jira are where teams manage their work. As the project administrator, you are the owner of your project.

It’s up to you to make your project easy to use so your team can get their work done. This involves assigning users to roles that are appropriate to their job tasks, configuring boards, setting up versions and releases, and more. We’ll go into all these tasks throughout this course.

You can also help the Jira administrator by understanding how Jira works. By being well-informed you can troubleshoot issues, and possibly resolve them, without having to escalate them to the Jira administrator. And when you do need to contact the Jira administrator you can help them by knowledgeably explaining the problem behavior or requesting changes to be made.

Next, we’ll look at the basic elements of a Jira project. This was covered in the Jira Essentials course and is being presented here as a quick refresher

Jira issue

A Jira issue is the name of an item of work that has been identified by the team. The term “issue” comes from Jira’s historic roots as bug or issue-tracking software. Every issue has an associated issue type. Each issue type can have unique screens and workflows associated with them. An issue can contain a lot of information. This information is broken down into fields. Fields include the name of the issue, its unique identifier, its description, comments, date of creation, current assignee, and many others. Custom fields can also be created to match your team’s desired business processes.

Jira project

A Jira project is a collection of related issues. A project is a way to organize work. The issues can be related in any way that the team desires. You can think of the issues of a project as the team’s “to-do” list.

The issues can be in different states, such as not ready for development, ready for development, in progress, and done. Jira therefore contains a record of the team’s work, allowing the team to do things like report on their work.

A Jira project is not necessarily a project in the traditional sense, which usually has a start and end date. The term “project” is used loosely to include work that has no planned end date. For example, a product that is planned to continuously be improved, with no plan to ever stop work on it. When this course refers to a “project”, it is meant to be a Jira project.

Projects have an associated type, depending on how the team wants to accomplish their work. When you create a project, you select its type, such as Kanban or Scrum. We will discuss these later in the course. Over time, the team can configure their project to use a custom agile methodology or framework.

Every issue in Jira is unique and belongs to just one project. The issues are the project’s work items. For instance, the HR Onboarding project may have issues such as creating an email account, supplying laptops, and assigning desks. The iOS project may have issues such as coding the login button, creating a help screen, and configuring iCloud. No issue can belong to multiple projects.

Jira automatically assigns a unique issue key to each issue. The letters before the dash represent a unique identifier for the project. This is called the project key. The issue number in the project follows the dash. Issue key values are unique to the Jira account. To ensure this, you can not have two projects with the same project key.

Project Board

A project board is a two-dimensional view of the work to be done by the team. The two dimensions become more important than with a personal to-do list because the work items can be in multiple states and be worked on by multiple team members.

Project boards visualize the work process of the team, and can be physical boards (such as sticky notes in columns) or digital boards (such as Jira boards). On a Jira board, each issue is shown as a card, which displays a convenient subset of the issues’ fields for easy visualization. The fields displayed on a card can be configured to match the team’s desires.

Each of the three Jira products is suited to different types of projects. Jira Software is ideal for creating software projects. Jira Service Management is ideal for any kind of service project. Jira Work Management is ideal for any business project.

Depending on which Jira products you have, you may have more than one project type available. The project types are Software (if you have Jira Software), Service project (if you have Jira Service Management), and Business (if you have Jira Software, Service Management, or just Jira Work Management).

Each project type has a number of project templates available. Project templates are sets of pre-configurations which are the default starting points. • Software projects give you Kanban and Scrum templates.

The Bug tracking template is also available for classic projects.

• Service projects give you IT service management (ITSM) and external service project templates, among others.

• Business projects (classic only) give you Project management, Task tracking, Content management, and more. Once you create a project, users can go to work with the defaults, or you can customize them to suit your needs.

Going forward, we'll concentrate on Software and won't go into details of Service Management and Work Management projects.

Jira Cloud comes with company-managed and team-managed projects (formerly called classic and next-gen, respectively).

This course covers company-managed projects. Company-managed projects have many options for planning, tracking, and reporting on your team's work.

They're powerful and highly configurable. Team-managed projects are fast to set up, easy to configure, and user-friendly. Only Jira administrators can create company-managed projects, but any user can create team-managed projects by default.

Also, project configuration can be shared between company-managed projects. Any changes you make to a team-managed project won't affect other projects.

Supplemental information: In the future Atlassian may introduce the ability to share configurations between team-managed projects.

Now, we’ll look at creating company-managed projects in Jira.

As the Jira administrator, you act as the project creator for your Jira community. A user who has the Administer Jira global permission is the only one able to create companymanaged projects for all products installed. Members of both the administrators group and the jira-administrators group have this global permission by default.

Here you see some of the project templates for Software project types. Kanban, Scrum and Bug tracking for the Software project type. Each project template gives you different functionality as a starting point.

When you create a project, choose the project type (and template) that meets your needs.

You also supply the name.

Use a descriptive name so the project is easy to find.

The project key will be used as the prefix of this project's issue keys (e.g. ’HR-100').

The key is automatically generated from the project name (the first letter of each word).

You can change it when you create the project and also later.

Choose one that is descriptive and easy to type.

After the project is created, the Project administrator can edit the project details as necessary.

For URL, you can use the link to a Confluence space, document repository, etc. for project documentation.

If you have a large number of projects, you can use project categories to categorize them – this is an optional feature in Jira. An Avatar (icon) makes the project easier to find. You can use one of the provided avatars or your own image. A description makes it clear what the project is for.

Supplemental information: For more information, see https://confluence.atlassian.com/display/JIRACORECLOUD/Editing+a+project%27s+details.

Once a project is created, it will appear in the list of projects on the Projects page in Jira. You must have the appropriate project permission (Browse project) to view a project. Permissions will be discussed in a later module.

In this module, we’ll explore project roles and permissions.

In this module, we’ll learn about permissions, groups, roles, and permissions schemes. We’ll look at some common project permissions, how to manage role membership, and how custom roles can be used to satisfy specific team requirements.

When discussing permissions in Jira, several key elements interact with each other. In this section, will examine those elements.

Jira’s administrators are responsible for managing user access and permissions in Jira. Each type of administrator affects different aspects of Jira.

A Site administrator manages the Jira instance grants access to users and adds users to groups. The Site administrator does not directly work with Jira or Jira projects.

A Jira administrator configures Jira, which includes configuring roles and permissions schemes, which we will discuss shortly.

A Jira project administrator uses the permissions configurations set up by the Jira administrator to grant permissions to various team members.

Permissions are settings within Jira that control what users can see and do. Jira has a variety of permissions: from whether users can create new projects to whether a user can see a specific type of comment on an issue. Permissions are different from application access, which is controlled by groups that have Use access for a Jira product (application). Global permissions allow Jira administrators to control functionality that is system-wide and project-independent. For example, whether users can see the other users in the application. Global permissions are granted to groups of users and can only be modified by Jira administrators. Project-specific permissions let you restrict project-related functionality to individual users, groups or project roles. For example, who can see the project's issues, create, edit, and assign them. Project-specific permissions can only be modified by Jira administrators.

Group memberships give users site and product admin permissions. Groups apply to all Atlassian applications on an organization’s site, such as Jira and Confluence. Site administrators create groups and manage membership. Global permissions are assigned to groups, and project permissions can also be associated with groups.

Project roles are similar to groups, except that while groups apply to the entire site, roles are scoped to a single project. Additionally, group membership can only be altered by Site administrators, whereas project role membership can be altered by project administrators. Project roles can be used in many places including permission and notification schemes, issue security levels, workflow conditions, and comment visibility. They can also be given access to issue filters and dashboards. However the core usage is for permission and notification schemes. While you could assign permissions and notifications to users and groups directly, roles are more flexible and sustainable.

Many Jira project configurations are implemented through the use of schemes. Schemes are essentially a container that holds a particular kind of configuration. For example, there are workflow schemes that describe how workflows behave, notification schemes that configure notification rules, and so on. All schemes are configured by a Jira administrator and then associated with one or more projects. In this way, a set of configurations can be defined once and then applied to any number of projects. A permission scheme determines who performs certain tasks in a project. It is simply a list of permissions along with users, groups, and/or roles they are associated with. In this example, the permission requirements in all development projects are the same. So the Jira administrator has created the Development permission scheme and applied it to all development projects. Any logged-in user with application access can browse projects and edit issues but a user needs to be in either the Administrators project role or the Scrum Masters project role to Manage sprints. When there are multiple entries in a particular permission like this, it’s treated as an OR statement. The user doesn’t have to satisfy both, but either of the choices. After the Jira administrator creates a permission scheme and assigns it to a project, the project administrator can add project to users to the roles listed in the permission scheme, granting the permissions associated with the role.

Now we’ll take a closer look at some of the project permissions.

Jira has two levels of permissions.

Global permissions apply to the entire Jira instance and determine things like whether users can see other user accounts and groups, share dashboards and filters, make bulk changes in projects, and so on. Global permissions are assigned to groups by the Jira administrator.

Project permissions apply to individual Jira projects and determine the types of actions users can perform within a project. Jira administrators config Issue security permissions allow the visibility of individual issues to be adjusted (within the bounds of the project's permissions). For example,

issue security permissions can let you set up types of issues that can only be seen by project admins or users in specific groups.ure project permissions using permission schemes that are then associated with individual projects. We’ll take a look at some examples of project permissions on the next slide.

Browse Projects is the most important permission. No matter what other permission the user may have (Create Issues, Delete Issues, etc.), if they do not have Browse Projects permission, then cannot see the project or any of its issues.

Transition Issues is needed above any other specific permission that may be used in a workflow condition. Schedule Issues allows users to set the Due Date. Normally, you only need Edit Issues permission to edit fields, but for Due Date, you need this Schedule Issues permission.

The Schedule Issues permission and the Edit Issues permission are both needed to rank issues in the backlog of a software board. Ranking is a feature that is only available to Jira Software users.

Manage Sprints allows users to Create, Schedule/Reorder, Start, and Complete Sprints in a software project. But boards (and hence this permission) are only available to Jira Software users; so they need Jira Software application access. Note that there is a distinction between

Assign Issues (which allows someone to make assignments) and Assignable User (which allows someone to be the Assignee).

Move Issues allows a user to move issues between projects and/or change an issue’s issue type.

For a full list of Jira project permissions, refer to this article: https://confluence.atlassian.com/adminjiracloud/permissions-for-classic-projects1001823931.html

In this segment, we're going to dive into Jira roles.

For every Jira project, a default set of roles is provided. Each role has specific significance and capabilities in a project. An additional default role, Component lead, is also created when a project utilizes components, which we will cover later in this course, The Jira administrator assigns one or more users to be a Project administrator for a project. The Project administrator can perform basic project configurations and is responsible for assigning team members to the other project roles. We’ll take a closer look at the default roles in the next few slides.

The Project administrator can edit the project details i.e. name, description, avatar, and URL as well as the project lead. But their most important responsibility is to edit project role membership. They can also define project components and versions. By default, when a project is created the jira-administrators group is assigned to the Project administrators role.

The Project lead is a person who manages the project. By default the Project lead is the project’s creator, but can be reassigned to be any team member. The Project lead can be designated as the project’s default assignee for newly created issues. This role is often fulfilled by the Project Manager or the Lead Developer.

The Default assignee is the person who is assigned to a new issue if no assignee is specified. There are only two choices: Unassigned (the default), or the Project lead. The Jira administrator can configure Jira to disallow unassigned issues, in which case the Project lead is the only choice.

The Board administrator is able to configure a specific Jira board e.g., add columns, configure card colors, etc. By default, a board’s creator is automatically assigned as the Board administrator. A board can have more than one Board administrator.

You should know how your team works and what each of them needs to do to do their work in Jira. Then you can set their roles and have the Jira administrator set their permissions in your projects appropriately. For example: • Some teams may be more hierarchical, like this Marketing team. They have one person, the Project Manager, who’s in charge and who will have the most control so that person will be the Project Lead and the project administrator. Other team members will be users with the ability to manage their own issues. • Other teams, for example agile Software teams, may want to manage their own projects and have everyone in the team have all the project permissions.

If the default roles are not sufficient to satisfy your team’s permissions requirements, the Jira administrator can create custom roles, which can then be referenced in a permission scheme and assigned to Jira projects, where they can be used like any other project role. Typical situations where custom roles are needed is when common permissions, that are widely granted to all users, need to be narrowly restricted to a smaller subset of users, or when certain users need to perform specific functions they normally aren’t able to do.

Most issue-related permissions are granted to the default group, jira-software-users. If this default group is assigned to, for instance, the Developers project role, you might be giving broad issue permissions to users who are not part of your development team. Some organizations are comfortable with this situation, but others prefer exerting more control over access to the team's backlog. In this case, the project admin can just remove the default group from the project role in question, then create a custom role to grant the permission to specific users.

By default, the Manage Watchers permission is associated with the Administrators group for a project. To grant selected administrative permissions to other team members, the permissions can be associated with a custom role, and selected team members can be added to the custom role

We’ll start by looking at what it means to configure a Jira board.

Jira offers two types of boards to track issues:

Kanban boards and Scrum boards.

Scrum boards are ideal for teams working in small cycles, or sprints. Scrum boards have a dedicated backlog where work can be planned and allocated to sprints, Scrum boards are sometimes referred to as “sprint boards” or “agile boards”. On the other hand, Kanban boards are excellent for tracking an ongoing stream of tasks, such as support issues or bug fixes.

By default, the leftmost column of a Kanban board serves as a backlog, but a dedicated backlog page can be enabled if desired. Scrum and Kanban are not mutually exclusive. Many teams like to use both of them, applying the correct tool for a given task.

Jira boards are the primary way team members interact with Jira, so it’s important to that boards are configured to meet the team’s needs. Fortunately, boards are highly configurable and offer many settings that affect their appearance and functionality.

Project administrators and Board administrators can configure Jira boards. Board administrators can be assigned on the Board settings > General page.

The Board administrator can perform the same board configurations as a Jira or Project administrator, except that a Board administrator cannot add or remove statuses

A poorly configured board can be confusing and difficult to work with. If your team can’t locate their issues easily, they won’t want to use the board.

A properly configured board, using card colors, swimlanes, quick filters, relevant columns, and meaningful information displayed on cards, promotes team adoption, and continued use, and effectively conveys overall project progress.

In this section, we’ll look at how board columns are tied to workflow status.

For this requirement, the team wants to have two possible statuses for issues moved to the Review column.

To satisfy the requirement, the Project administrator adds a Review column to the board, creates two new workflow statuses and adds them to the new column. A single column can be associated with any number of statuses. The Board administrator can also create the new column and add statuses to it, but cannot actually create new statuses.

When users work with the board, they will see the newly added Review column. When they drag an issue into the column, the possible status choices will appear, and the users selects one simply by dragging the issue on top of the status name.

Let’s look at what’s actually behind the scenes when new columns and statuses are added to a Jira board. Boards are tied to an underlying workflow. For Software projects, the simplified workflow is used for the board that’s created when the project is created. Here’s an example of a simplified workflow for a scrum software development project. The top screenshot shows the sprint board in the project. The diagram at the bottom shows the underlying workflow. Note the connection between columns and workflow statuses. This is the actual workflow that’s used for the board.

The simplified workflow is very basic and all its transitions are global transitions i.e. ALL. Global transitions allow any status in a workflow to transition to any other status (either from inside an issue or by dragging issues on the board). Here you see the default workflow for a Scrum software development project. It has only three statuses and issues can freely move between any statuses. The default simplified workflow for a Kanban project has four statuses. A simplified workflow has no conditions, validators, or transition screens on its global transitions. Also in the simplified workflow, the resolution is set and cleared automatically, and that setting can be made from the board. The simplified workflow can only be used if a board represents a single project. Also, if the board was created as a result of creating a project, the board will be using the Simplified Workflow. You can edit this workflow from the board configuration to add new statuses and columns. Also note the different colors of each status. Each of these represents a status category – To Do (blue), In Progress (yellow), and Done (green). You’ll see these colors in all types of workflows. These help you identify where issues are in their lifecycle, particularly in places where a large number of issues are rolled up, for example the Version Details page and Sprint Health dashboard gadget.

Here you see some of the things that can be changed with regard to the relationship between workflow, status, and columns of the board. You can create a new column on the board and then map a status to that column. You can also map a status to an existing column. It’s crucial that you map all statuses to columns. Otherwise issues in “unmapped” statuses will be hidden from the board. You can add columns to boards that are using the simplified workflow or any other type of workflow. But to add a status to a board the project must be using the Simplified Workflow. Adding a status to a board adds a status to the underlying workflow. The workflow now becomes a custom workflow.

The simplified workflow is an easy to use workflow. There are no screens for transitions and users can transition an issue from any status to any other status (drag freely between columns). Also users who are both board and project administrators can edit the workflow via the board configuration, adding statuses and columns. Once you edit a simplified workflow adding statuses and transitions, it is no longer a simplified workflow and becomes a custom workflow. A customized workflow is usually a more complex workflow. Often it has a specific sequence of steps rather than allowing every status to transition into every other status (global transitions). The Jira administrator may add conditions, user input validation and automated functions to transitions in the workflow. There could be screens that pop up during transitions that allow users to enter data for example, a resolution. Jira administrators are the only ones that can fully edit a workflow, Project administrators have limited editing capability for their project workflows.

Jira ships with a set of default statuses that are used by the default workflows. When editing your project workflow(s), don’t over-complicate your workflow. You want to get fine-grained visibility into the status of work, but building a workflow with 20 or 30 statuses results in a workflow nobody wants to use. It’s better to start with a simple workflow, and add statuses when you need them. When people enjoy using workflows, they’re more likely to keep issues updated, which means your data is more accurate and actually useful. Add statuses that reflect how people actually do their work. Add a new status is when work needs to be re-assigned to another person. Or when a piece of work is going to be in the same status for a significant period of time. This period of time will differ depending on the workplace and the overall period needed for the workflow to be completed. Often management will want to track more data for reporting. It’s important to think through a request for more data. Will that data help us make better decisions? Enable us to help our customers better? Will the proposed change be the best way to get that data, or is there a better way we should think about? Don’t gather data for the sake of data. That will slow down work and negatively impact your team outcomes. Don’t exceed around 7 statuses unless it’s complex change management, or a shared workflow where different phases will be used by different teams. If you add a status to your workflow, you may also need to update filters.

Stakeholders often want to have statuses for each part of the workflow. That’s generally a good thing, but remember: each status adds more transitions and complexity. Aim for simple and scalable instead. Whenever adding a new status to a workflow, make sure you have no other option. Let’s look at two examples. • Code review is an important part of the software development process. Jane, the development manager, wants to add a specific status called In Code Review so it’s clear to her team which issues are under active development, and which issues are awaiting review. Reviewing code is distinctly different than writing code, so it makes sense to add a new state. • Bill, the QA manager, wants to add new status called Failed Verification for all issues that don’t pass review by his team. I’d advise against doing this, as the test engineers can simply send any issue that fails review back to a previous state, such as In Development.

Now we’ll look at a specific board requirement and explore several ways to satisfy the requirement.

As you know, Kanban boards are structured for continuous work. There are no sprints or workflow restrictions in a Kanban board. Consequently, as tasks move through the board, they eventually land in the Done column where they can accumulate and clutter up the board. So how can we clean up completed issues from a Kanban board?

We’ll look at four ways to clear up a Kanban board’s Done column. The first three, utilize standard board configuration methods, while the fourth is an optional Jira feature for managing versions and releases, but it also happens to be a way of clearing issues of a board.

If all you need to do is hide aging issues that have ben completed, Jira provides a way to automatically hide old issues on a Kanban board that have been resolved. In the general board settings, select a time period from the Hide completed issues dropdown Resolved issues that are older than the selected time period will automatically be removed from the Kanban board. Note this may cause some reports to return different results than what's visible on the board, since reports only use the board’s filter query to determine the status of issues.

Another way to avoid Done issues from accumulating on your Kanban board is to modify the board’s filter. Here is an example of a JQL query that hides Done issues and issues that have been resolved in the last 5 days. If you want a resolved issue to become visible again in the future, should there be a comment or change added to the issue, use updated instead of resolutiondate in the query. This query can also be implemented as a board sub-filter or as a quick filter.

A sub-filter is a feature of Kanban boards only. The sub-filter refines the results of the board filter, and goes into effect whenever the board is viewed. Note that when using a sub-filter, some reports may return results that differ from what's visible on the

To avoid potential reporting discrepancies that can occur with sub-filters, a query can be implemented as a quick filter instead. However, instead of being automatically applied to the board, the user must activate the quick filter by clicking it when viewing the boardboard, because reports only look at a board’s filter query and do not factor sub-filter.

Another approach that has nothing to do with board configurations, is to use Jira’s optional version and release function. A version is a set of features released together as a single update to a product. By default, Kanban boards do not require issues to be pre-assigned to versions. This is because Kanban is designed for a continuous flow of work, rather than set iterations. On a Kanban board, you can choose to release a version at any point in time, grouping done issues into a single version. For example, if you are using Jira to manage the development of a product or manage the build of a house, you may want to define different versions to help you track which issues relate to different phases of your product or build (e.g. 1.0, 1.1, 1.2, 2.0, 2.0.1). Jira can help you manage, release and archive your versions. Versions can also have a Release Date and will automatically be highlighted as "overdue" if the version is unreleased when this date passes. Versions are defined in the project and are for that project only, they are not global. They help build out the roadmap for the project. And they allow repeated iterations of a project Versions are typically used in Software projects but are also available in Jira Core projects. Versions are managed by project administrators.

Issues can be assigned to versions from the backlog or from an issue’s Fix versions field. As a Project administrator, you also have the option to create new versions.

The Releases page displays the status of all versions, including previously released versions. New versions can be created from this page, as well. Clicking a version will display additional details and provide the option to release the version,

After clicking a version on the Releases page, the “Release hub” is displayed, providing a dashboard with real-time visibility into the status and progress of an upcoming release. Also the Release Hub, when integrated with other Atlassian development tools, automatically identifies issues that are marked complete but still have open pull requests or require reviews, as well as any other un-reviewed code or open builds. By ensuring that a completed issue is truly complete, Release Hub mitigates risks, replaces time-consuming status update meetings, and provides for a more confident and stress-free release process for the entire team. Click the Release button will release the version.

When a version is released, all issues associated with that version are removed from the board. The only exception are issues that are currently part of an active sprint. If there are issues belonging to the version that have not reached the Done column, you can either assign them to another version or choose to release them anyway

In terms of clearing issues from a Kanban board, the version release method has some pros and cons that should be considered: Version releases are particularly useful for the management of software projects where designated updates and fixes need to be documented and released. They bundle issues together and create an audit trail. For non-software projects, version releases may create unnecessary overhead and generate additional Jira metadata that's not necessarily relevant to the project, as well as generating additional notifications. We’ve seen how versions and releases can be used to clear issues from a Kanban board, but you will need to decide if this method is appropriate for your team’s projects.

In this module, we will learn how boards and projects relate to each other.

Here you will learn how boards and projects can be related. How to configure a board to display multiple projects, and how to configure a project to have both Scrum and Kanban boards. You will also create boards based on existing filters and copy boards.

In this section, we’ll explore the different types of relationships that are possible between Jira projects and boards.

When a project is created, you have the option to create a Kanban or Scrum board for the project, creating a simple one-to-one relationship between the project and its board.

But other types of relationships between projects and boards are also possible. A single project can have multiple boards. For example, it may make sense to create individual boards for each team that only displays the issues they’re working on. It’s also possible to have a single board that displays issues from multiple projects. For example, you may want to create a master board to display issues from multiple related projects or multiple teams.

A board’s filter query determines what projects and issues are displayed on the board. In its most basic form, a Jira board is simply a visual representation of a query result, so a board is only limited by what’s allowable in JQL. A board’s filter query is accessed under Board settings - General.

Now we’ll look at a specific use case for multiple projects on a single board.

This requirement calls for a board that displays issues from multiple projects. It should also be made clear on the board, what issues belong to what project. Let’s see how we can accomplish this

A board can be associated with multiple projects by creating a new board from an existing project or modifying an existing board’s filter query.

One way to associate multiple projects with a board is to create a new board, selecting the option to create the board from an existing project. Then in the Project field, specify multiple projects. Note that even though the board will query multiple projects, it still has a home project as indicated by the Location field. This simply means the board will be grouped together with other boards from the indicated project, but this does not determine what the board can display. In the above example, even though the board’s Location is Project B, the board is not required to display issues from Project B.

Instead of creating a new board, you can modify the filter query of an existing board to include multiple projects. You need to be the Board administrator to modify the filter query. If you are not the owner of the filter, you won’t be able to edit it directly. Instead, inspect the filter and clone it using Save As. Then change the board filter to the newly saved filter and edit it.

If the projects included in the new multi-project board have different workflows, the statuses from those projects may be re-mapped to different columns on the new board. To ensure issues and statuses are displayed correctly, you can create additional columns on the new board and rearrange the status as needed. This won’t affect the source projects.

To keep the board better organized, you can configure swimlanes by project, so each project’s issues appear in their own swimlane, making it easy to distinguish issues from the different projects.

Next, we’ll explore how a single project can have both Kanban and Scrum boards.

What if you have a Kanban project and you want to run some sprints for the project on a Scrum board? Or vice versa. You have a Scrum project, but want to track some ongoing project tasks that aren't tied to specific deadlines on a Kanban board. Or what if you started a Kanban project, but down the road, realize you now need the project to be a Scrum project instead. How can we add different types of boards to a single project?

Any number of boards can reference a single project. In the most general sense, a project can simply be thought of as a collection of tasks, or issues. And a board is just one particular view of those tasks and issues.

Since a project is just a collection of issues, and a board is simply a view of those issues, the project itself is neither a Kanban nor a Scrum project - it's simply a Jira project. You can choose to view work in that project either thru the lens of a Kanban board or a Scrum board. Yes, it's true that when you first create a project, you're asked to identify it as a Kanban or Scrum project, but you’re really doing is determining if the initial board for that project is a Kanban or a Scrum board.

When adding a Kanban board to a Scrum project, you may need to change the project's workflow so work can progress in the same way on both boards. For example, if workflow conditions are tied to a particular column and that column doesn't exist in one of the boards, tasks may not be able to advance. Other factors that may affect each board differently are issue type schemes, different estimation methods, and different work-in-progress limits.

In this module, we’ll learn about managing issues in Jira projects.

Here you’ll learn the differences between Jira’s default issue types, and you’ll learn how to configure issue field layout, create and apply components, bulk edit label values, and move issues between projects.

Let’s start by examining Jira’s default issue types.

All work is managed in Jira through issues. An issue represents an element of work that needs to be done. That work can be a task, a bug, a feature request or any type of work item about your organization. Issues are displayed on boards that indicate the current state of each work item.

The kind of work associated with an issue is typically indicated by the issue type. Jira provides default issue types depending on which Jira project you are working with: For Jira Software projects, the default issue types are Epic, Story, Task, Bug, Subtasks, Improvement, and New Feature. For Jira Work Management projects, the default issues types are simply Task and Subtask. For Jira Service Management projects, the default issue types are Incident, Change, IT help, New Feature, Problem, Service Request, Service request with approval, and Support. Issue types can have their own set of issue-specific fields and their own workflow rules.

Issue types are organized in a simple hierarchy. All issue types, including custom issue types, can have related subtasks, and optionally, issue types can be the children of an epic. Subtasks cannot have their subtasks. Custom subtasks issue types can also be created. We will examine each of the default issue types in more detail in the following slides.

Issues from multiple projects can link to a single epic. This makes it possible to use epics for the planning and tracking of large multi-project initiatives

Epics typically represent large features, often defined by product managers. Epics can span multiple projects, and when all work related to an epic is completed, then the epic is complete. Epics are typically used for roadmap planning and tracking in Jira.

Stories are typically used to express a high-level feature or goal from the user’s perspective, using non-technical language.

Tasks typically represent work that must be done, often in support of a story, and are usually expressed in technical terms. A task may or may not directly impact the user experience

Bugs are defects that impair the functioning of the product. Jira Software also provides a dedicated bug-tracking project template that can be selected when creating new projects. The bug tracking project does not include a board by default, but a board can always be added to a bug tracking project.

Subtasks represent smaller, more granular tasks that are related to their parent task. Subtasks are created within the context of a parent task. A single task can have multiple subtasks. The ability to have subtasks in Jira can be disabled by the Jira administrator.

Next, we’ll look at custom issue types.

In this use case, the team wants to track feature requests separate from bugs, and they want the Task issue type replaced with Engineering Task, and Story should be the default issue type for new issues, followed by a specific ordered list of issue type choices.

To satisfy the business requirement, the Jira administrator would: • Create a new Feature Request and Engineering Task issue types in the new standard project. • Remove the Task issue type • Change the order of issue types and set the default issue type to Story in the DEV: Scrum Issue Type Scheme (the issue type scheme for the new standard project).

Jira administrators can create custom issue types and assign them to projects using Issue type schemes. However, to reduce maintenance overhead of your Jira instance, you should always try to leverage Jira’s default issue types whenever possible. When configuring a project, you need to decide how to categorize issues. For example, if you need to distinguish between Internal and External Requests, this can be done with different issue types, with a Select list custom field, or even components. So you need to decide when issue types are definitely needed. You don't want to create issue types indiscriminately. There needs to be a reason.

New issue types are associated with workflows, field configurations, and screen configurations. All of these configurations are managed by the Jira administrator,

The Jira administrator configures the default issue type, as well as the ordered list of available issue types.

The Project administrator can configure the layout of fields on the issue details page for the issue types in a project. Fields can be re-ordered, conditionally hidden, or permanently hidden.

Next we’ll learn about Jira’s components feature.

In this requirement, the team wants to categorize their issues by product feature, geographic location, and business unit.

Components are an optional feature for grouping or categorizing issues.. Components can be anything that makes sense to you and your team. For example, components can map to different types of work within the project team. You might define components that represent different office locations, different functions, or different aspects of the application. Or you might choose to define components to represent different types of content (a web application has images, html files, css files, etc.). Using components makes it easier to look at the relationships of different elements of a product release - in effect, a taxonomy. Components are project-specific and do not span multiple projects.

Project administrators create components for their project. The Name field represents a component’s value. A component default assignee will override the project's overall default assignee. If someone creates an issue with more than one component, and the default assignees for those components are different people, then Jira assigns the issue to the default assignee of the component that is first alphabetically. If your project's team changes frequently, you can set the default assignee to a particular role. This can future-proof the default assignee of a component, in the case that someone leaves your project.

Components are applied to issues by assigning the pre-configured component values to an issue’s Component’s field. Multiple component values can be assigned to a single issue

The Components page displays all of the component values that have been configured for the project along with selected details, including the number of issues associated with each component value. Clicking a value displays a list of issues the value has been assigned to.

Components can be used to gain interesting insights into the software development process: • Perhaps the project manager is concerned about the staffing needs for an upcoming project. The Issue Statistics dashboard shown here, illustrates the relative number of issues per component. It can easily pinpoint an area where the resources are lacking. • A dashboard showing the number of unresolved (open) issues per component can help identify trouble spots. • For the product owner, concerned about the roadmap, a dashboard showing unresolved issues per component over the next 3 versions is useful. • To get a snapshot of the product change log, create a dashboard that shows resolved issues per component per each previous version.

It’s possible to configure board swimlanes based on component value. However, be aware that if an issue has multiple component values, the issue will only appear in one of the swimlanes

Components is not one of the selectable swimlane criteria. Instead, you will need to select the Queries criteria and enter individual conditions for each component value. If new components are added to the project, the query conditions will need to be updated to include the new values.

It’s possible to use the Labels field as a simpler alternative to components. But you should be aware of the benefits and drawbacks of Labels before deciding to use them: Label values can be created by any user and can apply to any project in the system. Issues can be retrieved by searching for label values. But because value creation and entry is unrestricted, label values are prone to typos and inconsistent values, making search results potentially unreliable. The uncontrolled creation of labels makes it difficult to maintain and scale your Jira projects. And since label values are available system-wide, project-specific reporting based on label values is not possible.

This module is a basic introduction to Jira automation.

You’ll learn the benefits of Jira automation, explore the core elements of automation configuration, and create an automation rule.

In this section explore the benefits and features of Jira automation

An automation rule can act as a custom feature for your team. It is a way to extend the value of Jira by enabling your team’s desired process. Automation can enforce requirements. Ultimately, automation minimizes the complexity of the Jira instance for your team.

Jira Software offers several ways to automate functionality, including workflows, bulk editing of issues, third-party Marketplace apps, and custom coding. Jira Service Management also has blueprints, and Team-managed cloud projects have rules. In this module, we’ll look at the no-coding automation feature built into Jira software.

Jira automation enables you to implement automation using simple rule definitions. No coding is required. Automation rules can extend the value of Jira for your team.

Some examples of Jira automation include: Automatically creating subtasks when an issue is created, randomly assigning high-priority issues to team members, sending a message when an issue’s due date is approaching, or hasn’t been commented on for a day, or automatically closing old issues having no activity.

Project administrations can create automation rules for their projects, while higher-level administrators can create automation rules that apply to all projects.

Project administrators can access automation under project settings.

Now let’s look at the basic building blocks of an automation rule.

Creating an automation rule is as simple as specifying a trigger event, a test condition, and the automated actions to be performed if the condition is true.

The trigger is an event that initiates the automation rule. It can be the creation or modification of an issue or simply the amount of time that has elapsed.

Once the trigger initiates the automation rule, specified conditions are checked and must be passed before the automated actions are carried out.

If all conditions are true, the automated actions are carried out. Actions include the creation or updating of an issue, sending a message, making an HTTP request, or affecting multiple issues based on a JQL query.

Now we’ll walk through the steps of creating an automation rule.

We want our automation rule to automatically create a set of sub-tasks whenever a new issue of type Task is created. For this scenario, we want the sub-tasks to be related to the creation of a blog post.

The creation of a new issue should initiate the automation rule, so the trigger is “Issue created”.

We only want the automation actions to be carried out if the new issue is a Task. Using the Issue fields condition, the automation rule will check for the issue type in the issue’s Issue type field.

The Create sub-tasks action will automatically create one or more sub-tasks. We can specify the details of each sub-task in the configuration screen.

After the automation rule is named and saved, it can be tested.

Each automation rule has an audit log that displays when the rule was modified or run, and if the run was a success.

In this module, we’ll how reports and dashboards can provide timely and useful information about projects and issues in Jira.

Here, you will learn about the benefits of reporting and monitoring projects. You will run five useful reports, create a dashboard, and learn about some useful dashboard gadgets.

Let’s begin by understanding the benefits of agile metrics.

In any agile program, it's important to track both business metrics and agile metrics. Business metrics focus on whether the solution is meeting the market need. Agile metrics measure aspects of the development process. Tracking agile metrics can reduce confusion, identify problem areas and roadblocks, and enable project teams to better adapt and evolve.

Jira provides a large collection of useful reports to help gain insight into your projects. Whether you are a Scrum or Kanban team, each of these reports can help the team better understand their development process and make it easier. And even more reports are available in the Atlassian Marketplace.

Let’s explore some helpful Jira reports.

Jira Software provides 21 reports, but in this module, we’ll focus on five key reports that can provide valuable insight into the progress of your projects and team performance. Reports are run against boards and reflect the status of a project’s board. For a user to run a report, they must be able to view the board (Browse projects permission).

The sprint burndown report provides an indicator of how work in a sprint is tracking against project progress at any given point in time. The burndown report is only useful if an estimation metric has been used in the planning of the sprint.

The x-axis represents time and the y-axis represents the amount of estimated work, using the sprint’s estimation metric (story points, days, etc.). The blue line represents the estimated amount of work remaining as the sprint progresses. The grey area represents non-working days. The orange line represents actual work remaining. Generally speaking, as long as the orange line remains below the blue line, the sprint should be on track for the scheduled completion time. If the orange line remains above the blue line, it may be difficult for the team meet the sprint deadline.

This slide lists some potential indicators and remedies that can be gleaned from the burndown report.

The epic burndown report and release burndown report are similar, except that one tracks sprints, while the other tracks version releases. But they are interpreted in the same way. Both reports track work over an extended period of time, gathering data from multiple sprints or releases.

The y-axis represents the amount of work, using the project’s estimation statistic. The vertical bars along the x-axis represent individual sprints, or releases, with the first bar indicating the total amount of estimated work at the start of the project. Each bar is divided by color into work completed, work remaining, and work added, or scope creep, during the sprint. Based on the team’s progress, the report automatically predicts how many sprints it will take to complete the project. This prediction is indicated by one or more grey bars that appear to the right of the completed sprints.

This slide lists some potential indicators and remedies that can be gleaned from the epic and release burndown reports. These reports are particularly good at identifying scope creep. Tolerating scope creep during a sprint is bad practice, but scope change within epics and versions is a natural consequence of agile development. The epic and release burndown charts keep everyone aware of the ebb and flow of work inside the epic and version.

As the team completes more sprints, the velocity report can help the team more accurately estimate future work. The report calculates the team's velocity, which is essentially the average amount of work the team is capable of completing during a sprint. Let's say the product owner wants to complete 500 story points in the backlog. We know that the development team generally completes 50 story points per iteration. The product owner can reasonably assume the team will need 10 iterations (give or take) to complete the required work. The more iterations, shown in the report, the more accurate the forecast

The y-axis represents the estimation metric used by the team. Each vertical bar represents a completed sprint, divided into estimated estimated work versus the actual amount of work completed. The report displays the team’s last 7 sprints.

It's important to monitor how velocity evolves. New teams can expect to see an increase in velocity as the team optimizes relationships and the work process. Existing teams can track their velocity to ensure consistent performance over time, and can confirm whether a particular process change made improvements or not. A decrease in average velocity is usually a sign that some part of the team's development process has become inefficient and should be brought up at the next retrospective. Use retrospectives to identify possible causes for disparities in estimated work versus completed work.

The control chart measures a team’s cycle time, which is the total time issues spend in work until they are done. Measuring cycle time is an efficient and flexible way to improve a team's processes because the results of changes are discernable almost immediately, allowing them to make any further adjustments right away. The end goal is to have a consistent and short cycle time, regardless of the type of work. Teams with shorter cycle times are likely to have higher throughput, and teams with consistent cycle times across many issues are more predictable in delivering work. While cycle time is a primary metric for Kanban teams, Scrum teams can benefit from optimized cycle time as well.

Now we’ll look at Jira dashboards.

Jira dashboards are pages that can be configured to display up-to-the-minute information about projects and tasks. Jira provides a default dashboard, but users and administrators can create additional dashboards for their own use or to be shared with others.

A Jira dashboard is made up of individual components called “gadgets”. Gadgets are blocks that dynamically access and interact with information from across your instance. Jira provides dozens of configurable gadgets, and even more gadgets are available in the Atlassian Marketplace.

Jira’s default dashboard is configured by the Jira administrator and is available to all users in the system. Users can configure their own dashboards and keep them private or share with other team members.

Creating a dashboard is very easy. Simply select a page layout, then select and position gadgets on the page. Most gadgets have configuration settings that enable you to target and display the information you require.

Dashboards are extremely useful when applied correctly. Before creating a new dashboard, identify its scope, purpose, and target audience. Does the dashboard focus on sprints, tasks, individual performers? Is it for your use only, or will it be useful for specific users or roles? It’s important to avoid information overload on a dashboard. Too much information, especially if its unfocused, reduces the usefulness of a dashboard. Try to limit the number of gadgets to more than 6, and make sure the information being displayed is related and relevant. Avoid creating multiple dashboards that display similar information, especially if they’re being shared with other users.

Now let’s look at some useful gadgets in more detail.

The Sprint Health gadget provides a quick overview of how work is progressing on an individual sprint. What if you need to track multiple scrum teams together? Use several instances of the Sprint Health gadget alongside the Agile Sprint Burndown gadget to get a quick overview of how all teams are progressing towards a common goal.

The Sprint Burndown gadget is a miniature version of the Burndown report and provides a good indicator of how likely the team is to complete their work on schedule. For this chart to be accurate, estimation in the beginning of the sprint is critical.

The Filter Results gadget displays the results from one of your saved filters, so it is extremely flexible and allows you to use JQL to deliver the information you need.

The Two-Dimensional Filter Statistics gadget enables you to create a table by crossindexing two data sources. For example, you can create a filter to retrieve all open issues in a particular project. You can then configure the gadget to display the statistical data on this collection of issues, in a table with configurable axes, such as Assignee versus Issue Type.

The Assigned to Me gadget conveniently displays all issues that are assigned to you. You can configure which fields to display as columns in the gadget, and can sort the results by any column.

In this module, we'll cover how to create and configure team-managed projects.

Here you'll learn how to create team-managed projects, control access to your projects, add issue types, and add fields for issue types in your projects. You'll also learn how to configure a project board and customize the features of your project.

Jira Cloud comes with company-managed and team-managed projects (formerly called Classic and Next-gen projects, respectively). This course covers team-managed projects. Company-managed projects have a huge number of options for planning, tracking, and reporting on your team's work. They're powerful and highly configurable. Team-managed projects are fast to set up, easy to configure, and user-friendly. Only Jira administrators can create company-managed projects, but any user can create team-managed projects by default. Also, project configuration can be shared between company-managed projects. Whereas any changes you make to a team-managed project won't affect other projects. Supplemental information: In the future Atlassian may introduce the ability to share configurations between team-managed projects.

By default, any logged-in user can create team-managed projects. Out of the box, Jira gives users the Create team-managed projects global permission. Jira administrators can prevent users from creating team-managed projects by managing which groups are granted this permission.

Here you see project templates for team-managed projects. Currently, there are two Software projects - Kanban and Scrum. You also see three of the Service project templates - IT service project, General service project, and External service project. There are more. More templates are being added all the time.

When you create a team-managed project you supply the name. Use a descriptive name for the project so it’s easy to find. The project key will be used as the prefix of this project's issue keys (e.g. ’GA-10'). The key is automatically generated from the project name (the first letter of each word). You can change it when you create the project and also later. Choose one that is descriptive and easy to type. You also choose the appropriate access level. We'll discuss these on the next slide. A project icon makes the project easier to find. Use a meaningful icon to make the project easier to find. You can use one of the provided avatars or your image. Supplemental information: For more information, see https://confluence.atlassian.com/display/JIRACORECLOUD/Editing+a+project%27s+details.

When you create a team-managed project you can choose from three levels of access:

• Open allows anyone with access to your site to create and edit issues in the project. This means that project team members don't have to be separately added to the project, because they can already do their work there.

• Limited means that anyone with access to your site can view and comment on issues, but they cannot create and edit issues. Team members that need to create and edit issues must be added to the project.

• Private means that only people who have been added to the project can see the project. This is a way to prevent the project's issues from being widely visible in the organization. Other people on your site will never know the project exists. Jira administrators can see private projects in the project directory, but they don't have access to view or interact with a private project's issues (unless they have been added to the project). You can change the access level for a project at any time.

Team-managed software projects come with the following project roles: Project administrators can do most things, like update settings and add other administrators to the project. They can manage features, customize issue types, and add rules on the board. Members are a part of the team. They can create issues, edit them, comment on them, move them into different statuses, and generally collaborate on your project's work. Viewers can search through and view issues in your project. Project administrators can add people to their projects and set their roles. The person who creates the project is automatically given the Administrator role. If a user is assigned multiple roles in a project, the most permissive role wins. There are also other roles for Jira Service Management team-managed projects that aren't covered here. Supplemental information: For details on what users can do in each role, see http://go.atlassian.com/cloudnextgenperms.

The project administrator can edit the default issue types and add new issue types in a team-managed project. For example, team-managed Software Scrum projects come with the Epic, Bug, Story, Tasks, and Sub-task issue types by default. Team-managed Kanban projects come with Task and Sub-task issue types by default. You can customize your issue types to match any method of project management you want. You can delete any of the default issue types in the project, you can rename the issue type or update the description, etc. You can also create new custom issue types. For example, in a Software Kanban project, you may want to add a Document issue type for any updates needed to the documentation.

Fields on an issue are divided up into different sections:

1. Description fields - appear in the main content area of your issues.

2. Context fields - appear on the right side of your issues.

3. Hide fields below dotted line - appear on your issues when someone completes the field. If the field is empty,

it's hidden. Users select Show more when viewing the issue to see and interact with the hidden fields. This becomes important when you add fields. Let's look at that ...

The foundation of every Jira issue is its key, summary, and a status. But some tasks require more information to help along the team taking on that work. Project administrators can customize each issue type to show different fields. You can add, reorder or remove fields and also create custom fields. By default, Jira adds a few fields to your issue types that we think help provide context to your project's work. They are Summary, Description, Status, Assignee, Reporter, and Labels. Jira also comes with a few commonly-used fields you might consider adding, for example, Priority and Due Date. When you add a field you select what part of the issue you want it to appear in: Description, Context or Hidden (see previous slide). Don’t add too many fields as this can confuse users and they will often leave half of them empty which creates bad data. Supplemental information: For more information, see http://go.atlassian.com/cloudnextgenfields

Customizing your team-managed project workflow is simply done by editing the board. Drag columns to be in any order you want. Click + to create new columns. And you can set column limits. The column with highlight if the limit is exceeded. An example of editing your workflow is if you added a Review step to your work process. You could add a Review column and move it to be between In Progress and Done. Don’t add too many columns as the board will become difficult to use.

Team-managed projects are very flexible. You can start with the features of a kanban project and as your needs change you can add features to make it a scrum project i.e. by turning on Sprints and Estimation. You can change these features at any time. So it doesn't matter what template you initially choose when creating a team-managed project, you can always change it.

Team-managed projects don't have schemes so any changes made in a team-managed project apply only to that project. If you edit the workflow or the issue types, create any new issue types, add fields to screens, etc. no other projects are affected. And if, for example, you add a new issue type to a project. When you go to the Issue Types Jira administration page you won't see the issue type there. That page only shows classic project issue types. Note that in the future, team-managed projects may be able to share project configurations.

Atlassian Marketplace apps add new functionality to your team-managed projects. Use them to integrate third-party tools and add-ons into your project. When your Jira administrator integrates third-party apps to your Jira site, project administrators might have the option to display or hide the app's functionality in their team-managed projects and adjust their settings. Go to project settings > Apps. Most apps have a toggle that changes their display setting. You can easily display or hide the app from your project by flipping on or off this toggle. In this example, we see the Slack integration apps page. You can display or hide the Slack panel on issues in the project. You can also add channels to receive notifications. You may not see a settings page for every app installed on your Jira site. Each app’s settings options are provided by the developers who built them. Supplemental information: If you want more information about an app or how to set it up for your project, check the developer’s website or Atlassian Marketplace listing.

New features are being added to team-managed projects all the time. Check out upcoming features in the Atlassian roadmap at atlassian.com/software/jira/whatsnew/next-gen.