Welcome to this Atlassian University course on managing Agile Boards and Reports.

This course has been designed to give you a comprehensive review of Scrum and Kanban
boards and their configurations, as well as board-related reports.
And here is what you will learn:
• We’ll learn about the two types of Jira Software agile boards and how to determine
the right board type for your team.
• We will dive deep into all the board configurations so you can customize yours to fit
your business requirements.
• We will analyze data from agile reports and see the impact of scope and estimation
changes.
• And finally, we will explore various board caveats and the related tricks and
troubleshooting tips.
To succeed in this training and understand the use cases presented, you will need the
following:
• Knowledge of agile principles, including Scrum and Kanban methodologies.
• Practical experience in project administration including all the project settings.
• Good understanding of project schemes.
• And you need to have expertise in JQL, since a lot of successful board configuration
depends upon it.
Here is our agenda.
Let’s begin with the overview of visualizing work in Jira through agile boards.
“Visualizing information can give us a very quick solution to problems. We can get clarity
or the answer to a simple problem very quickly,” says David McCandles – British data-
journalist, writer and information designer.
So why visualize work? For one, visualizing work is one of the principles of agile projects.
The more we can see, the quicker we can understand the current state of the project and
focus the teams that are working on it.
Hence work management is easier. We can quickly add, remove, and prioritize the work
being done as well as update individual work items.
And finally, as David McCandles said, it’s also much easier to spot problems and
bottlenecks, and identify solutions and process improvements.
There are three main ways to visualize work in Jira; boards, reports, and dashboards.
• Agile teams use boards to help visualize and manage their work. They can sometimes
be referred to as task boards or project boards, or more specifically as Kanban boards
or Scrum boards.
• A board can be a physical board like a whiteboard with sticky notes or it can be a
digital project board as we see in Jira.
• Boards are a two-dimensional view of the work. You can visualize the entire process;
via the board columns and the underlying mapping of workflow statuses to those
columns.
• And you can see the current status of all the individual work items.
• The work in Jira are the issues. And Jira boards display issues as cards with a subset of
the issue fields for easy visualization.
• Each board has agile reports that displays the information and data analysis about
the issues found on the board.
• The board type determines which reports are available in that board.
Dashboards are the third way to visualize your team’s work in Jira.
• You can add numerous gadgets to a dashboard – such as Filter Results and Issue
Statistics – that show issues from one or more projects or a saved filter.
• There are also several gadgets that are specifically related to agile projects. When
configuring them, you must choose the name of the board instead of a project or filter.
The gadget will display data from the board you select.
Jira has two board types for teams using scrum or Kanban methodologies, though they
are not mutually exclusive, and many teams like to use both of them, applying the
correct tool for a given task.
The Scrum board has two views by default; Backlog (which contains the product backlog
and the sprint backlog) and Active sprints. There is also a Versions panel and Epics panel
in the backlog that allows easy drag-and-drop of issues to associate them with a version
and/or an epic.
By default, in the other Jira agile implementation, only the Kanban board is available. But
the Backlog view may be enabled, if desired. If the backlog is enabled, then you also have
a choice to display epics in a panel in the backlog, and not as cards on the board. The
versions panel is not available in Kanban. Instead, you can Release issues from the Done
column.

Let’s look closer at both Scrum and Kanban.

Scrum is for teams that plan their work within time-boxed periods called sprints in which
they create potentially-shippable product increments. There are three main parts of the
Scrum framework.
Scrum artifacts are tools that provide project transparency, enable shared
understanding, and enable inspection and adaptation. They include the product backlog,
the sprint backlog, the sprint goal, sprint boards and reports.
The second part of the scrum framework is the roles related to scrum, including the
product owner, scrum master, development team members and stakeholders.
The third main part of the scrum framework is the events related to scrum. These are also
called ceremonies or meetings. The sprint guide considers the sprint as a container event
for the other events. These ceremonies include the sprint planning meeting, daily
standups, the sprint review and the sprint retrospective.
• A product backlog is a dynamic, ordered to-do list for the project
• and can include stories, features, improvements, bug fixes, etc.
• Issues near the top of the backlog are the closest to being worked on, so they usually
have more details than the lower items.
• The product backlog is managed, continually refined and ordered by the product
owner.
• Modifying the product backlog is called product backlog refinement (or backlog
grooming).
• The sprint backlog is a subset of the product backlog; the list of issues to be
completed during the sprint.
• Issues in the sprint backlog are either in the current (active) sprint (or will be in the
next started sprint).
• It contains issues that are well-defined, broken down, and estimated.
• The sprint backlog is assigned to, worked, and completed by the development team.
• The total of all their estimates is the sprint commitment.
• The sprint goal represents the objective of the sprint's increment. It is agreed to by the
team.
• The sprint goal is reached by completing the issues in the sprint backlog.
• A scrum rule is that the sprint goal does not change during the sprint; the sprint is
considered a success if the sprint goal is reached.
• Why have a sprint goal? The first reason is that it provides a coherence to the product
increment. This means that the features are related, so that the product increment is
valuable rather than building a collection of unrelated features. This also results in the
scrum team working together to achieve the sprint goal.
• The second reason is that it enables flexibility with the sprint backlog. Projects are
complex, and even though the sprint duration is relatively short, the team can not
predict the future and will learn and adjust during the sprint. There has to be flexibility
somewhere. The sprint goal remains fixed during the sprint, but the issues that achieve
the sprint goal can be modified as long as quality is not decreased. This means that
there is flexibility in the makeup of the sprint backlog as the sprint is worked on. The
sprint goal provides guidance for decisions as the team makes adjustments.
• During the active sprints, the team strives to complete work items in the sprint
backlog.
• They move stories across different columns – using drag-and-drop from left to right –
until they are done. Each column represents a workflow stage.
• They can also quickly identify any impediments so they can be cleared and work can
continue.
• The Active Sprints board facilitates daily standups (sometimes called daily scrums).
Scrum boards have many reports available, including
• Burndown Chart
• Burnup Chart
• Sprint Report
• Velocity Chart
• Version Report
• Epic Report
• Epic Burndown
• Release Burndown
• Cumulative Flow Diagram
• And Control Chart
We will discuss these in the third module.
Now let’s look at Kanban. It’s a smaller and more lightweight framework. All agile
methods by definition are lightweight, but Kanban is lighter as compared to the others
like scrum. It does not define as much of the agile process as scrum does. For example, it
is up to the Kanban team to decide which ceremonies to use, if any. Because it is a more
bare-bones way to achieve agility, Kanban is often used as an evolutionary approach to
agile. It doesn’t require reorganization, new types of meetings or new roles. You can start
implementing it now and become more agile over time.
Kanban is for teams that work with a continuous flow of issues. New issues are
continuously added to the backlog and are always being prioritized, usually by the
business team. Work is also continuously being finished before starting new work.
Kanban is excellent for service-based teams, customer support, help desk and operations
teams, and for other ongoing work that has to be prioritized but does not involve
planning.
A main focus of Kanban is to improve the flow by limiting work in progress before
starting new issues. At any given time, the team should only be working on what they
can handle sustainably. This has many benefits. There is less multitasking, less waste,
and less rework; which leads to increased productivity and faster delivery due to the
improved flow. Bottlenecks are identified much quicker because there are fewer issues in
progress at any time and problems more easily visible. Identifying and fixing those
bottlenecks continuously improves the work of the team. And in turn, this promotes
teamwork as everyone works together to clear the impediments.
For many steps of a process, it is better for someone working on the next step to pull the
work from the previous step rather than having it pushed on them when the previous
step is finished. Pulling work is common on agile, self-organizing, empowered teams
because it enables team members to select their work – when they have availability –
rather than being assigned work when they don’t. Pulling also maintains a sustainable
pace. Kanban uses both pull and push. For example, when new issues are ready to be
worked on, they are pushed from Backlog to the Selected for Development. When a
person is ready to work on the issue, he pulls the issue (using drag-and-drop) from
Selected for Development into the In Progress column. When the developer is done, he
pushes the issue onto the Done column. The overall Kanban process is a pull system.
• By default, the entire prioritized backlog of work is visible to the team in the Kanban
board.
• Tasks are prioritized and then pulled from the top of the queue by a team member
when they are ready for more work.
• Work is also completed one-by-one in a continuous process.
• Issues can be released from the Done column on the board, periodically or as needed.
By default, Kanban backlog is in the first column of a Kanban board, along with the rest
of the columns. This may be sufficient if there are only a few issues in the backlog. But as
a backlog grows, viewing and scrolling through these issues can become difficult.
• Therefore, it’s possible to enable the Kanban backlog.
• If you're planning work for your team, you have a separate and bigger space to create
and rank issues and select issues for your team to start working on. You can triage and
plan before sending the tasks to the team for development by dragging them up into
the Selected for Development area (or to the next status in your workflow, if it has
been customized).
• These items then appear on the main Kanban board, so team members can focus on
working without the distraction of planning. And managers can see the progress of
what is actually being worked on.
• The Epics Panel can also be (optionally) enabled in the Kanban backlog. If it is enabled,
it has the same functionality as in Scrum boards.
As mentioned earlier, work in progress limits can improve the flow of value by preventing
multitasking and focusing the team on issues already in progress before starting new
ones.
• You can set the minimum and/or maximum number of issues allowed in certain board
columns.
• If the number of issues in those columns falls outside the threshold, the background
color of the column changes; yellow (if there are fewer issues than minimum) or red (if
there are more issues than the maximum).
• What WIP limits should be set to depends on the specific project and the team.
• They may start with no limits and see if the issues are flowing nicely, then add limits
as the process starts to show problems
• Or they may add them to discourage multitasking.
• Or to set minimums on steps that the team tends to neglect.
• Backlog or done columns generally don’t have limits, because those statuses do not
contain the team's work in progress.
Kanban boards focus on improving the flow of issues through the workflow. There are
two reports available to facilitate this;
• the Cumulative Flow Diagram
• and the Control Chart
Boards are automatically created when the Jira administrator creates a project using the
Kanban or Scrum template.
And they can be created manually at any time by anyone with Jira Software product
access. New boards can be either Scrum or Kanban, regardless of which project template
was used to create the project initially. This is true even for the Basic software
development template which doesn’t have a board by default.

Bottom line, a single project can have multiple boards, and a single board can contain
the issues of multiple projects. We will cover this topic in more depth later in the course.
Board configuration is a matter of determining the content to show and the features to
enable or customize. Boards can display all or a subset of issues from a single project or
from multiple projects. This depends on the underlying board filter query. The Kanban
board also has a sub-filter.
Both types of boards contain plenty of features and configuration options, such as
swimlanes, quick filters, card colors, card layout, and much more.
Most of those features are available in both types of board – Scrum and Kanban – such
as those shown here.
A few are only available in one or the other. For example, it makes sense that only scrum
boards allow estimation and the ability to create, start, and complete sprints.
And therefore, that Kanban boards, have a release functionality instead that releases all
the issues in the Done column, on-demand, as-needed. The scrum boards don’t have this
because they work in pre-defined time-boxed iterations.

There are a few other such differences based on the board type, which we will identify
throughout the course.
So here is a typical use case when determining the board type to choose.

Doug needs a board for his team that works in a continuous process. But he wants a separate
place to plan and prioritize tickets before team members start work on them.

We need to decide which board type to use and how to configure it.
The short answer is that Doug needs a Kanban board to support his team’s continuous
process. And he needs the backlog enabled so he has a separate place to plan and
prioritize tickets.

If you would like to see more detail and a virtual walkthrough of the solution, you can
read through the pdf solution guide that we’ve provided.
Now a quick knowledge check. Samantha needs to improve the continuous flow of work
for her service team. She wants to constrain their work in progress and focus them on
removing bottlenecks before they start work on new issues. Which board feature will
meet her needs?

A. Backlog
B. Card colors
C. WIP limits
D. Estimation
Hopefully, that was a snap for you. The answer is C. Let’s review why.

A. Incorrect. The question provides clues that Samantha is using a Kanban board. The
team works in a continuous flow and it’s a service team. In a Kanban board, the backlog
is not available by default. But even if it’s enabled, it is used for prioritizing and planning
items in the backlog only. It won’t help constrain work in progress.

B. Incorrect. Cards can be colored based on various criteria. However, it doesn’t make
sense to add card colors based on status because all issues in a column will always be
that color, regardless of how many there are.

C. Correct. Setting minimum and maximum WIP limits on particular board columns will
bring focus to exceeded thresholds and focus the team on progressing and finishing their
work in progress.

D. Incorrect. Estimation is used only in Scrum boards to guide the sprint commitment and
predict team velocity.
Now we will review all the configuration options so you can learn to customize boards to
meet the needs of your team. Most of the options apply to both board types: Scrum and
Kanban, though we will point out the differences in places where they occur.
Each board is configured independently of other boards; even if they are based on the
same project. This is great because each agile project has different team members,
different processes, different personal preferences, etc. In total there are 9 board
configuration areas, as shown here. Estimation, however, is only available for Scrum
boards. Agile is very responsive to change. Reconfiguring boards is just one way we can
respond to changing needs. So board configuration is a continuous process.
The first tab in configuration options is called General. It includes the following 7 settings
for both board types:

• Board name: It’s good practice to name the board appropriately, especially if it
contains only a subset of issues from a project, issues from multiple projects, or if it is
based on other more complex criteria.
• Administrators: The list of those who can configure the board – in addition to all the
Jira administrators (who can always configure the board, as well). It's best practice to
list at least one backup board administrator in each project.
• Saved Filter is very important and is often a great source of confusion. Only issues
included in the board’s saved filter will be visible on the board. We will go into this a
lot more soon.
• Shares defines with whom the saved filter – and hence the board itself – is shared.
That is, a board is available to all users who can view the saved filter on which the
board is based. Note that users also need the Browse Projects permission for the
project(s) whose issues are shown on the board.
• Filter Query is the JQL query of the saved filter.
• Ranking allows you to rank issues on a board using drag-and-drop and to add issues
to sprints. It also enables Jira Agile to group sub-tasks together underneath their
parent issue. Rank is a custom field that contains a numeric value. That way you can
define the relative importance of an issue across multiple boards. As a best practice,
issues on boards should be ranked.
• Projects in board shows the name of the project, or multiple projects, whose issues
are shown on the board. Occasionally, the projects on the board cannot be listed
because of the complexity of the board filter.
Finally, there are two additional settings underneath the Filter section, which are
available only in Kanban boards.

• Kanban board sub-filter which – by default – allows further filtering of issues for
unreleased work.
• Hide completed issues older than is the second setting. It can speed up your board by
hiding issues you're no longer working on. The dropdown options are 1 week, 2 weeks,
4 weeks, or Show All.
Every board has a filter that defines the issues that will be shown on the board.

In the simplest case, we have a board where one team is working in one project. Hence
the board only contains the issues from that project. The filter query for the board filter
would be something like “project = ENG ORDER BY Rank ASC” or possibly a subset of the
project based on some field, like issue type, components, or labels.
For example, you could have multiple teams working in the same project and single
board. Let’s say the teams use the Labels field to identify the work they do. Then the filter
query would be “project = ENG and Labels in (eng-team, dev-team) ORDER BY Rank ASC”
Or you could have a team that is working in a board that contains issues from multiple
projects. Then the filter query would be “project in (ENG, DEV) ORDER BY Rank ASC”
Or a board where multiple teams are working in multiple projects and hence accessing
issues from those multiple projects on their board. Once again assuming that the Labels
field is used to distinguish the work items of each team, then the filter query would be
“project in (ENG, DEV) and Labels in (eng-team, dev-team) ORDER BY Rank ASC”

Bottom line, regardless of which team(s) and which project(s) are involved, a board can
be configured to display the issues they need to see. This just depends on the JQL query.
Here is an example of a Kanban board configuration.
1. Notice that the saved filter shows issues from two projects (AKAN and TIS) and is
shared with both
2. that Ranking is enabled
3. that this has a Kanban sub-filter. This is the default sub-filter query: “fixVersion in
unreleasedVersions OR fixVersion is EMPTY”. However, it can be modified to filter
based on other criteria, as we will see in a later module.
4. This board hides issues older than 2 weeks.

If multiple teams are working a single board, there are some caveats, however, because
the permissions, workflow, issues types, etc. in those projects could be different. We are
going to explore this next.
The columns settings include:
• Column constraint: which, as we discussed earlier, allows you to set minimum and
maximum WIP limits for columns. The choices for Column Constraint is None, Issue
Count, or Issue Count, excluding Sub-tasks.
• Days in Column: Shows dots representing the time an issue spent in a particular
column on the board.
• Simplified Workflow: shows whether the board is using the Simplified Workflow or
whether the Software Simplified Workflow is unavailable due to customization
complexity.
• The rest of this configuration page is devoted to the mapping of columns and statuses.
Let’s look closer at this mapping.
Boards and workflows are closely related. As we learned earlier, the board visualizes the
workflow and the progress of work. In the simplest case, we have a board whose
workflow only has 3 statuses: To Do, In Progress and Done. Each column only contains
one status and both column and status have the same name. The columns of a board
represent the steps of the process.
When a user drag-and-drops a card from one column to another, the issue is transitioned
to the Status mapped to that column. In this case, issue changes status from To Do to In
Progress.
And likewise, if you transition the issue from the issue view or perform a bulk operation,
then – behind the scenes – the issue is moved to the corresponding column on all the
boards where that issue appears.
So the issue status and issue location within a board column stay in sync.
This simple workflow and board configuration is, in fact, the default configuration of the
Scrum board that is automatically created when Jira administrators create a new project
using the Scrum software development template.

The project has multiple issue types and all of them use this same single Simplified
Workflow.
The Simplified Workflow is
• easy for team members to use and understand.
• It is managed automatically by Jira Software.
• It can only be used if a board represents a single project; and the workflow
determines which statuses are available.
• All transitions are global so issues can be moved freely from any column to any other.
• There are no transition screens
• And no conditions or no validators
• And it’s possible to add and remove statuses in a Simplified Workflow.
• To do so, you must be either a Jira Administrator
• or a project administrator who is also a board administrator. Because of course, you
must be a board administrator to modify any of the board configurations.
Here, the Approval status and column was added to the Scrum board.
Meanwhile, here is the default configuration of a Kanban board. Its status and columns
are Backlog, Selected for Development, In Progress, and Done.

It is automatically created this way when a Jira administrator creates a new project
using the Kanban software development project template.
To enable the Kanban backlog, you drag the Backlog status to the leftmost area
designated for this purpose. Then delete the Backlog column itself. When you return to
the board, you will see the Backlog view as we learned earlier.
So far, this has been rather straightforward. But remember that a board displays the
issues returned by the JQL query of its board filter. And that can get complex.
We will start easy with one project, DEV, and one issue type, Story. Stories are indicated
by a little green Story icon and a green bar on the left of each card. That’s because the
board is configured to display colors by issue type. We will look at card colors later.
Now we add a second issue type, Bug, indicated by a red icon and red card color. Still
from the same project.
Or – most commonly – let’s show all issue types from a project. We add 2 Tasks, as
indicated by the blue icon and blue card color. We will skip Epics and Sub-tasks for now.
Now we add 3 issues (1 Bug and 2 Tasks) from a second project, TIS .
And 2 more issues from TIS with a new issue type, Request, indicated by an orange
question mark icon and orange card color.
The complexity comes with the possibility of multiple workflows.
• For example: Dev Workflow Scheme
• uses the Story workflow for Stories with the statuses Backlog, In Progress, Done.
• The Bug workflow for Bugs with the statuses New, In Progress, Awaiting QA, Resolved.
• And Task Workflow for Tasks with the statuses To Do, Working, Review, Closed.
And because there are TIS issues in the board filter for the board, then
• the TIS workflow Scheme is also reflected on the board.
• The TIS project introduced the TIS Request workflow for Requests that has the
statuses Open, In Progress, Done.
• And just because TIS also uses the Bug and Task issue types, it doesn’t mean that their
workflows are the same as the ones in the DEV project. They could be different, as
well.
Such complex boards are difficult for users to understand and for administrators to
maintain.
• That is why it is best practice to keep the workflows as simple as possible and to
share workflow schemes among projects, especially those projects where the teams
may work together in a single board. Jira has a process that can be performed by Jira
administrators to help simplify workflows.

There are a lot more caveats when it comes to boards with multiple teams, projects,
issue types, etc. – not just when it comes to workflows but also permissions and other
configurations. We will return to those caveats in our final module. For now, let’s just
return to our Kanban board configuration for three more concepts.
The first concept is Unmapped statuses. Statuses must be mapped to an appropriate
column in order to be visible on the board. Here, Reviewing and Testing appear in the
rightmost area of the board under the heading Unmapped Statuses. These statuses are
part of one or more workflows on the board but have not been mapped to any columns.
There may or may not be issues in those statuses. But if there are, then they will not be
visible on the board.

As a best practice, all statuses should be mapped to a column. Of course, there may be
situations where a board administrator chooses to leave some statuses off the board.
So the second concept is mapping multiple statuses to a column. A column can contain
two or more statuses which can be ordered horizontally, so we can take those two
unmapped statuses and…
Put them in the Working column, which now has 3 statuses mapped to it.
And as a best practice, you should name columns appropriately, especially in these kinds
of scenarios where there are multiple statuses.
• So in this case, we renamed the column to “In Process” since it now contains more
than just the Working status.
When users transition into such a column, they will see separate perforated sections for
each available status in the column. They can select the one to which the issue should
be dropped (and hence which status will be assigned). Users must have the correct
permissions so depending on the workflow conditions, if any, they may not see all of
them.
The final concept is Definition of Done. Column configuration is important, particularly the
leftmost and rightmost column.
You can see that each column has a dark gray, blue or green color as shown here.
The single leftmost column will always be dark gray, representing items in a “To Do”
state, so it can be statuses like Open, New, To Do, or Backlog as shown here.
The single rightmost column will always be green, representing items in a “Done” state
(as per design guidelines) and it can be statuses like Done, Closed, Resolved.
The middle column (or columns if you add more) are always blue, representing items in
progress. So here it includes the Selected for Development column and status, and the In
Process column with its three statuses.
The definition of Done has an impact on reports. A number of reports and gadgets show
data related to whether an issue is new, in progress or completed. And in simplified
workflows, dragging an issue to the Done column (regardless of what statuses are in
there) will set the Resolution to Done.
This example demonstrates the various things we have just covered.
1. We can see that the Kanban backlog is enabled. Issues in Backlog status are visible in
a separate backlog view.
2. Kanban backlog will show the Epics Panel because the setting is enabled, as well.
3. Work in progress limits are enabled because Column Constraint setting says “Issue
Count”. In some columns, the minimum and/or maximum number of issues will define
whether a yellow or red highlight will be displayed to bring attention to exceeded
limits.
4. Issues dragged to Done column have their Resolution set and are considered
Resolved in reports, gadgets, etc.
5. Issues in the Review status will not display on the board because the status is not
mapped.
6. Also, we see two statuses mapped to one of the columns. So when dragging-and-
dropping an issue from the In Progress column, the user will be able to choose either
status to transition to.
7. And which workflow is the board using? The Simplified Workflow which means there
are no conditions or validators, and all transitions are global.
A swimlane is a row on the board that can be used to group issues. The setting “Base
Swimlanes on” determines how those issues are grouped. The options include:
• None which means the board will not display any swimlanes
• Assignees: groups issues by their assignee. And you can then select whether you want
to display unassigned issues below or above the other swimlanes.
• Epics: groups issues under their epic. Issues not assigned to an epic will be shown in
their own group at the bottom. Epics with no issues on the board will not be shown.
• Projects: which is especially helpful on boards that show issues from multiple
projects.
• Stories: which group sub-tasks under their parent issue. Issues without sub-tasks are
shown in their own group at the bottom.
• Queries: It groups issues by JQL queries. Let’s look at 3 examples.
Here is an example of a board’s swimlane configuration based on Assignees.
• First, we see issues assigned to Alana Grant
• then Max Taylor
• And then the Unassigned issues shown below the other swimlanes.
Here is an example of a board’s swimlane configuration based on Stories. This is the
default setting in newly-created Scrum boards. Here, we see:
• A swimlane for Story TIS-45 with one sub-task
• and TIS-68 with two sub-tasks
• Then all the other issues without any sub-tasks.
Here is an example of a board’s swimlane configuration based on Queries. This is the
default setting in newly-created Kanban boards.
• There is an Expedite swimlane
• And Everything Else.
And this is how the Swimlane configuration looks in Board Settings. There is only one JQL
query for “priority = Blocker” for the Expedite swimlane, which shows all issues with the
highest priority. And then everything else in the second swimlane.

Issues are evaluated from top to bottom in the table. So unless an issue has the Blocker
priority, it will end up in Everything Else.
And of course, you can write your own queries in either board type. And those queries can
be fairly complex, as shown here. This is why you need to be a JQL expert to configure
boards. There are several more board configurations where you can use JQL.
And again issues are evaluated from top to bottom to determine in which swimlane they
will appear.
• By default, a board displays all the issues returned by the JQL of the board’s filter (and
potentially sub-filter for a Kanban board).
• Quick filters can be used to further filter the issues appearing in the Backlog or the
Active sprints/Kanban board based on an additional JQL query (or more)
• They are configured by board administrators
• And can be used by individual users to temporarily affect only their own display of the
issues on the board.
• They function as an on/off toggle.
Every newly-created board comes with two default ones as shown:

Only My Issues à shows issues assigned to the current user viewing the board
Recently Updated à shows issues updated within the last two days
And of course, you can customize these, as shown:

By adding a filter to see Only Bugs

Only issues which have a component, etc.
And this is how those 4 quick filters appear on the board. Two of them are toggled ON as
indicated by the gray fill. So while there are (probably) many more issues on this board,
we are now only seeing those which have been updated within the last day and have
one or more components.
Card color configuration allows you to choose a method for assigning colors to your
cards. You can choose the colors being assigned from a palette. The setting “Colors
Based on” includes:
• None: which means the cards will not have a colored edge.
• Issue Types: so each issue type on the board will have its own color
• Or each Priority
• Or by Assignees: so each assignee will have their own color.
• And once again, you can configure colors by JQL Queries
Here is an example of a card color configuration by Assignee.
• Alana’s cards have a red edge
• And Kevin’s have a yellow edge.
• And so on for other assignees.
Card layout determines what fields are displayed on a card. Customizing the cards for
your boards can help you bring the right information to your team's attention, at a
glance, without relying on people clicking cards to view the issue details.
• Cards can be configured to show up to three extra fields.
• In Scrum boards, you can add 3 fields in the Backlog and 3 same or different fields in
Active Sprints board
• In Kanban boards, you can add 3 fields to the Kanban Backlog (if it is enabled) and/or
to the main Kanban board.
In this sample Scrum board, we have added 2 fields to each card in Active Sprints:
• Component (like Space Travel on TIS-68 or Mobile Apps on TIS-131)
• And Labels (like webstore_outage on TIS-131)
Estimation is available in Scrum boards only. As part of planning for sprints, issues can be
estimated when in the Backlog to get an idea of how much work (or effort) an issue will
take and therefore, how much total work is being committed to in a sprint. Estimation is
an activity central to scrum development and helps to inform the team’s velocity.
There are two options to configure in a scrum board. Estimation Statistic represents how
your velocity will be measured from sprint to sprint against these estimates. You can
choose:
• Story Points: the most commonly used option.
• Original Time Estimate field: By default, this is specified in minutes, but you can use
hours, days, or weeks, depending on your Jira system configuration.
• Issue Count: which means estimation is based on the number of issues in the sprint.
The 'Estimate' field will not be editable in this case.
• And finally, you can base estimation on any numeric custom field in your Jira system.

Estimates are entered on issues in the backlog in the Issue Detail View.
There is also a configuration option for the Time Tracking statistic. You can choose
• None: in which case issues will burn down their Estimation Statistic value upon
completion (usually Story Points). Or you can use
• Remaining Estimate and Time Spent: in which case you will track time against issues
using Jira's Remaining Estimate and Time Spent fields.
By default, these fields are specified in minutes, but you can use hours, days, or weeks,
depending on the unit of time selected in Jira system configuration.

Note that this is fundamentally different from using the Estimation Statistic for
burndown, in that values do not burn down when an issue is completed — instead, values
only burn down when users enter Time Spent or set the Remaining Estimate to a new
value.
• The goal of estimation is for the team to achieve reliable velocity. Velocity is the
number of estimation units (basically, the amount of work) that a team can complete
within a sprint. Any metric type will work to determine a team’s velocity, but Story
Points are most common. And we will explore why in just a moment.
• In order for velocity to be reliable – and to be reflected accurately in reports – issues
should be estimated when in the Backlog before the sprint is started. This becomes
the sprint commitment.
• The team should also complete their sprints on time because reports (especially
Velocity charts) rely on completing sprints within the same time-boxed duration
(commonly 2 weeks).
• The team should avoid scope changes (either adding issues to an active sprint or
removing them). Scope changes have an impact on your report quality.
• Finally, all statuses should be mapped to columns otherwise unmapped statuses will
not be shown in reports.
Estimation improves over time.
Especially when it involves everyone on the team (developers, designers, testers,
deployers). Each team member brings a different perspective on the product and the
work required to deliver a user story. Oftentimes, teams use different techniques such as
planning poker to do estimation.
As we mentioned before:
• Story Points are the most common estimation statistic.
• Story points are a relative measure of the amount of work required to complete an
issue. They are provided in a Fibonacci-like format: 0, 1, 1, 2, 3, 5, 8, 13, 21…. For example,
an issue that is assigned two story points is assumed to involve about twice as much
effort as an issue that is assigned one story point.
• Story points are used to help the team decide how many issues can be completed in a
sprint. Each team will estimate work on a slightly different scale, which means their
velocity will naturally be different. This, in turn, makes it impossible to play politics
using velocity as a weapon.
• Using Story Points, versus hours, reduces anxiety around accuracy. Sprint estimation
becomes more and more reliable with practice. You can use actual hours, but it's not
reasonable to assume that all hours of a week are productive. Dates don’t account for
the non-project related work that inevitably creeps into our days: emails, meetings,
and interviews that a team member may be involved in. Dates have an emotional
attachment to them. Relative estimation removes the emotional attachment.
Developers have a general sense of how much they can accomplish during a 2-week
sprint - allowing for over or under estimating.
• By default, the Story Points field is only available to issues of type 'Story' or 'Epic' (not
'Bugs' etc). But this can be changed by associating the Story Points field with other
issue types and then specifying the screens that the Story Points field should be
displayed on.

• Don't assign time values to story points. Doing this obviates the main reason to use
story points in the first place.
This example demonstrates the various things we have just covered.
1. First of all, this is an Active Sprint as we can see.
2. Story TIS-30 has an estimate of 2 Story Points
3. Story TIS-12 is unestimated, which means that estimating it during the sprint will be
considered Scope Change and will register on reports.
4. And TIS-8 is a Bug and (by default) the Story Points field is not available on Bugs, so
there is no estimation lozenge at all on this card.
The Working Days configuration allows you to highlight or exclude non-working days
from reports and gadgets. They apply to the following reports: Burndown Chart, Sprint
Report, Epic Report, Version Report, Control Chart; and the following gadgets: Sprint
Health Gadget, Burndown Gadget. The settings are:
• Region and
• If your team has a different time zone from that of the server, select the team's Time
Zone.
• Standard Working Days: checkboxes for Monday through Sunday so you can select all
the weekdays during which your team typically works.
• And in Non-Working Days: click Add Date to specify holidays or one-off dates during
which your team will not be working.
Here is an example of the Working Days board configuration:
• for a team in Israel which works Sunday through Thursday
• With (some of) their particular holidays entered as Non-Working Days
You can see the non-working days during a sprint in reports, such as the Burndown Chart
shown here.
• The checkbox is checked to “Show Non-Working Days” in the legend at the right
• And so the gray columns are shown on those days. Work is not expected to occur
during these timeframes.
The configuration of the Issue detail view
• allows you to add, delete or reorder fields on the Issue Detail View
• so that the information shown on the selected card is customized for the needs of your
team.
• You do this by updating fields in various sections
At left is how an Issue Detail View has been modified from the default.
• And at right, you see the Issue Detail View of one issue.

We have covered all the board configurations, so let’s go to a Use Case followed by a
knowledge check.
Claudia approaches you with a request to help her update her board configuration.
She says, “I need some board changes:
• add testing into the process and ensure that development is done before testers pull
work into Testing
• have only 3 issues being tested at a time
• show the Platform field on each card
We need to decide which board changes will meet Claudia’s needs and how to make
those changes.
In short, Claudia’s needs three updates to her board:

• Add two new statuses: “Development Done” and “In Testing”. The reason we need two
statuses is that there needs to be a clear delineation between “development is done
so testing can begin” (developer pushes to this status) and “tester has begun and is
currently Testing” (testers pull to this status when they are ready). This is an example
of push-pull in Kanban flow.
• We also need to add a maximum column constraint of 3 on the In Testing column.
• And we need to add the Platform (custom field) to the card layout on the board.

For much more detail on this solution, see the pdf that we’ve provided.
Your team wants to see issues organized into 3 groups from top of the board to the
bottom, and the rest of the issues beneath them:
1. Issues labeled “system” or “error”
2. Issues with a component
3. Unassigned issues

Which board feature meets their need?

A. Swimlanes
B. Card layout
C. Card colors
D. Issue Detail View
Did you ace it?

A is Correct. You can configure swimlanes by queries where you write the JQL to
determine which issues to show in each swimlane. So, the queries would be (1) “labels in
(system, error)”, (2) “Components is not empty”, (3) “Assignee is empty” and the
Everything Else swimlane is always added by default.

B. Incorrect. Card layout can show additional fields like Labels and Components, but it
will not group them horizontally from top to bottom.

C. Incorrect. You can configure card colors using the same JQL queries as in answer A
above. However, this will only display the color on the issues. It will not group the issues
by the color.

D. Incorrect. Issue Detail View will display fields about each issue, but it does not group
issues.
Agile reports help monitor the progress of sprints, epics, and releases, control the
burndown rate, identify problems and bottlenecks, and continuously improve velocity
and cycle time.
Agile is about adapting to changing environments and requirements. Reports are a key
tool related to being agile. Like with boards, agile reports
• help to visualize the work of the team
• To help you assess the progress of current work (commitment vs. actuals) and respond
if needed
• And review what has been done in the past to continuously improve in the future
• They promote transparency – allowing anyone with access to see and have a common
understanding of the current state. The transparency means that there should be no
surprises about the delivery of the project.
• They help with troubleshooting. For example, certain reports can clearly show process
bottlenecks.
• Reports also help with planning the work of the team. They are commonly used in
planning meetings to help see the historic progress of the team and provide more
accurate planning and estimating.
Agile reports are board-specific; that is,
• they will only include data about the issues that match your board's saved filter. And
remember that the board filter doesn’t always include just one project nor all the
issues in a project.
• The concepts of To Do and Done depend on column-status mapping as discussed
earlier, especially the “Definition of Done”
• And scrum reports rely on consistent use of the estimation statistic (usually story
points) to be valuable
In Scrum boards, we have 10 reports. They are all shown on a single page when you go to
the “Reports” link in the left-hand side project navigation and view “All Reports”. But we
will group them together into the types of information they show.
• Burndown-type of reports which show the present state. This includes:
• Burndown Chart
• Burnup Chart
• Epic Burndown
• Release Burndown
• Status-type of reports which show the past. This includes
• Sprint Report
• Epic Report
• and Version Report
• And Continuous Improvement-type of reports which help improve the future. This
includes:
• Velocity Chart
• Cumulative Flow Diagram
• and Control Chart.
These last two reports – now shown in red and marked with an asterisk – are the only 2
reports (out of the 10 total) which are available in Kanban boards.

So, we will discuss the first 8 reports in the context of Scrum and then switch to Kanban
boards to discuss the last 2 reports Let’s begin.
• A Burndown Chart shows the progress that the team is making during a sprint and
tracks the total work remaining. The sprint backlog starts with a certain number of
issues, each with an associated number of story points or other estimation statistic.
• The chart shows the actual versus the estimated amount of work to be done in a
sprint.
• Hence, the report projects the likelihood of achieving the sprint goal
• Helps the team manage its progress and respond accordingly.
Let’s look at this example.
1. The horizontal x-axis in a Burndown Chart indicates time
2. The vertical y-axis indicates the total amount of work effort estimated to complete
all the issues in the sprint; hence it uses the total of the estimation statistic, in this
case, Story Points, but it could be another configured Estimation statistic.
3. You see grey columns which represent non-working days; no burndown is expected in
these timeframes.
4. The guideline line shows the average burndown that should occur in order to finish all
work items in the sprint timeframe. If the grey 'Guideline' line does not show, the
sprint may have been started before any issues were assigned to it.
5. The red line represents the actual burndown. The mapping of statuses to the Done
column on your board determines when an issue is considered completed.
6. When you click on a data point, you see more detail. There was a burndown on March
17 when issue TIS-45 was completed (with an estimate of 2 Story Points).
The bottom of the Burndown Chart contains the detail of all data points in chronological
order. It shows:
• the date of the event
• Which issue it was
• what the event type was (e.g. Scope Change or Burndown)
• More Event Detail (e.g. Issue added to sprint, Issue completed, Issue reopened, etc.),
• the resulting Increase
• or Decrease in Story Points
• and the Remaining Story Points until completion of the total sprint commitment.
The Burnup Chart provides a visual representation of a sprint's completed work
compared with its total scope. So, you can see the amount of work completed vs the
amount of work remaining on a day-to-day basis.
• Track your team's progress towards sprint completion
• Helps identify problems related to scope creep
• And note that Story Points on sub-tasks are not included in the Burnup Chart. (Only
Story Points on parent tasks are included.)
1. The horizontal axis represents time in days.
2. The vertical axis represents the amount of work and can be measured in different
ways such as story points, issue count, or estimates. In this case, it’s Story Points.
3. The chart shows the red work scope line
4. The spikes in work scope mean that something has been added to the milestone. This
information can be crucial at retrospective to understand if, for example, too much
work has ben added or the work has been more complex than estimated.
5. The green completed work line means completed stories, tasks, etc.
6. And the spikes in the green completed work line indicate an issue has been
completed; like the one shown on July 20.
7. The grey Guideline is a theoretical line showing the daily completion necessary to
meet the deadline. The distance between the lines on the chart is the amount of work
remaining. When the project has been completed, the lines will meet.

The chart contains a similar data point detail table like the Burndown Chart.
Now onto the Epic Burndown. Recall that an epic is a large user story that can be broken
down into a number of smaller stories. Stories are (hopefully) completed in a single
sprint. The work for the Epic (which contains all those stories) will often span many
sprints.
• The report shows you how your team is progressing against the work for an epic,
namely working through each of the issues that the epic contains.
• It is based on the estimation statistic that your board is using, usually Story Points.
• You can see if work for the epic was added or removed during some sprint and
affected your team's overall progress
• And you can predict how many sprints it will take to complete the work for an epic,
based on past sprints and changes during the sprints.

This report is similar to the Epic Report but is optimized for scrum teams that work in
sprints — which makes tracking much easier.
Let’s remember that when we talk about the numbers of things completed, we are
referring to the Estimation Statistic, which is Story Points in this case, not the number of
issues.
1. This report is showing an epic named “PRJCTC-1” (which we can see in two places, top
left and bottom left) with 3 completed sprints, represented by bars 2, 3, 4. The first bar
represents the original estimate of story points at the start of the epic
2. The light blue portion of each sprint bar shows the work remaining at the start of
each sprint. Which is 14 Story Points at the start of “PRJCTC Sprint 1”
3. The light green portion of each sprint bar shows how many Story Points were
completed, which happens to be 3 Story Points in “PRJCTC Sprint 1” and “PRJCTC
Sprint 2”, but only 2 Story Points in “PRJCTC Sprint 3”
4. The 3 gray sprint bars are predictions into the future. It is based on the velocity of
completed Story Points for the last 3 sprints, which – in this report – happens to be
the only 3 completed sprints so far. So based on the velocity in this epic (3 story
points per sprint) and the fact that we have 9 Story Points remaining at the end of
that last Sprint, the prediction is that it will take 3 more sprints to complete the rest
of the work in the epic, if the velocity remains the same.
5. And as usual, there is a table at the bottom of the chart that has details of the issues
completed in each sprint.
The Release Burndown report is just like the Epic Burndown report but shows you
information about the progress of Releases (Versions) rather than Epics. In Jira Software,
there is no “release” entity — a version is equivalent to a release (hence, the term “version”
is often used instead of “release”).
• The report shows how your team is progressing against the work for a release.
• As usual, it’s based on the estimation statistic used on the board.
• You can see how quickly your team is working through the backlog,
• See how work added and removed during the sprint has affected your team's overall
progress,
• And helps predict how many sprints it will take to complete the work for a version,
based on past sprints and changes during the sprints.

This report is also similar to the Version Report but is optimized for scrum teams that
work in sprints — which makes tracking much easier.
 The format of the report is identical to the Epic Burndown Report, so we are already
familiar with the sprint bars and the meaning of the blue and green portions. We’ll just
focus on what is new.
1. This time we select a Version Number from the dropdown. It’s “TIS 1.8” in this case.
2. There is a Viewing option in this report and the previous one to “Align sprints at the
base of the chart”. When unchecked, you will see any of the dark blue portions
(representing Work Added) below the light blue portion of Work Remaining. This is
actually quite helpful as it is easier to spot the scope changes. On this report, you see
a bit of scope change that we didn’t see in the Epic Report. 5 Story Points were added
in Sprint 2, 3, and 4
3. We can also do some math here. Light green section + light blue section = total work
in the version, that was originally estimated at the start of the sprint.
4. Light blue section + dark blue section = total work in the version, that is remaining at
the end of the sprint.
5. Sprint 6 is currently active and there were 23 Story Points to be done.
6. Since our velocity for the last 3 sprints has been 22, the projection is that we have 1
sprint remaining to complete the Version.
The Sprint Report contains a nice summary of the sprint.
• The Sprint Report shows the list of issues which were Completed in the sprint or Not
Completed (and hence either added to the next sprint or to the backlog)
• It shows scope changes, including Issues added to the Sprint after it started (indicated
with an asterisk) and Issues removed after the sprint was started.
• It reflects the team’s initial commitment. The values for each issue's estimate are
recorded at the time the sprint is started – namely, what the team actually committed
to. And changing the Estimate value after the sprint is started will not be reflected in
the Sprint Report. If you see no Story Points, it means the team didn’t estimate that
issue. And zero means the team added a zero Story Point value. You can see all
changes by switching to the Burndown Chart instead.
• The report is useful for mid-sprint progress checks and Sprint Retrospective meetings.
• Because it highlights team’s overcommitment or excessive scope creep.
1. The top of the report has a mini burndown chart followed by the different sections for
2. Completed Issues
3. Including those Added after the start of the sprint as indicated with an asterisk. In
this case, all 4 completed issues were added to the sprint after the start time.
4. Issues Not Completed in the sprint. And any Issues Removed from Sprint are shown
below those not completed.
The Epic Report shows a list of complete, incomplete, and unestimated issues in an epic.
• It is particularly useful in planning work for an epic that may extend over multiple
sprints.
• You can use the Epic Report to understand the progress towards completing an epic
over time,
• and to track the amount of remaining work that's incomplete or unestimated.
Here’s what this report tells us:
1. There are a total of 17 total Story Points in this Epic, PRJCTC-1
2. Of which 8 Story Points are Done
3. Which corresponds to 4 issues
4. That we can see in the “Completed Issues” section of the table below
5. And although all the issues were initially unestimated when added to the epic, they
have now all been estimated and there are zero unestimated issues.
Let’s look at Version Reports.
• Version Reports show your team's progress towards the completion of a version. And
it shows you the predicted Release Date, based on your team's average rate of
progress (velocity) since the start of the version, and the estimated amount of work
remaining.
• It does not include issues of a 'sub-task’ type.
• It shows 'Released' versions but not 'Archived' versions.
• The horizontal axis starts on the version's Start Date; or if no Start Date is specified,
the date on which an issue was first added to the version.
• The graph shows the state your version was in at any given point in time, in terms of
your total and completed Story Points (or other Estimation Statistic of your choice),
• so that you can see how the scope may have changed, and how you are progressing
towards completion of the estimated work
This report reads much like the Epic Report, hence we will focus more on the blue lines.
As you review it, ignore the years and focus instead on what the graph is telling you
visually. It’s a very quick and powerful way to see that your release won’t ship on time.
1. You see a vertical line for today and for the Release Date listed on the Version. And
you see three predictions, based on your average daily velocity and the amount of
estimated work remaining.
2. the Predicted Release Date (the blue line) – that is, the date at which you can expect
all issues in your version to be complete
3. the Predicted Release Date (Optimistic) (shaded area to the left of the blue line) – that
is, the earliest date by which you might expect the version to be complete. (It is
calculated by adding 10% to the average daily velocity.)
4. the Predicted Release Date (Pessimistic) (shaded area to the right of the blue line) –
that is, the latest date by which you might expect the version to be complete. (It is
calculated by subtracting 10% from the average daily velocity.)

Of course, in this case, the 10% deviation doesn’t help us. But the report is a clear
example of the value of visualizing work. In one quick glance, we see Today, Release Date
and a Predicted Release Date much further in the future.
Now let’s look at the Velocity Chart.
• The Velocity Chart shows the amount of value (the sum of all issue estimates)
delivered in each sprint
• It shows the sprint commitment (what the team committed to do) and the actual
velocity (what they completed)
• This enables you to predict the amount of work the team can get done in future
sprints. It is useful during your sprint planning meetings, to help you decide how much
work you can feasibly commit to.
• As the team improves its estimation, its velocity generally improves, so these charts
usually trend upward.
Here you see a sample Velocity chart. The grey bar indicates the total number of story
points planned for a given sprint and the green bar indicates the total of “completed”
story points. And, once again, completion is based on board columns according to the
Definition of Done.
1. The sprints are on the x-axis.
2. The Estimation Statistic is on the y-axis.
3. Prior to the first sprint, the team estimated that it would complete 40 story points,
shown with the grey bar.
4. It actually completed only 37 story points, as shown by the green bar. The velocity of
the team for Sprint 1 was 37 story points.
5. You can also see this in the information table. In sprint 2, the team optimistically
estimated that it could complete 53 story points. It actually completed 47.
6. Notice by the bars for Sprints 2 through 4 that both the sprint commitment and the
team’s velocity are increasing.
7. In Sprint 4, the team finally met their sprint commitment of 57 story points.
A cumulative flow diagram is a popular report for Kanban projects. It is one of the two
available Kanban reports in Jira. This is because maintaining and improving the flow of
the team is a high priority. Jira provides automatic, real-time reporting. As the team
updates issues, the reports are automatically updated. All you have to do is view them.
• A Cumulative Flow Diagram (CFD) is an area chart that shows the various statuses of
work items for a board (which may contain issues related to a whole application,
version, or sprint).
• The horizontal x-axis in a CFD indicates time and the vertical y-axis indicates cards
(issues).
• Each colored area of the chart equates to a workflow status (i.e. a column on your
board).
• The CFD can be useful for identifying bottlenecks. If your chart contains an area that is
widening vertically over time, the column that equates to the widening area will
generally be a bottleneck.
• You can also see overall flow improvement and how well the team is keeping up with
the backlog. You can't really see individual issue problems with this diagram but you
can use other reports or views to focus on specific issues.
• This report can be refined by deselecting columns or swimlanes or clicking on one or
more quick filters.
1. You can see from this diagram that for the first few days, all of the issues were in the
backlog status, indicated by the orange band.
2. The number of issues in the backlog status increased from 1 to 5 before the first issue
was moved to Selected for Development, which is the second band here.
3. The third band represents issues with the In Progress status, so you can see that
actual work on an issue started here.
4. The final band indicates issues with a status of Done. You can see that the Done band
increases nicely over time, indicating pretty good flow.
5. You can see that the backlog has almost been depleted, indicated by the shrinking
orange band.
The Control Chart is the second report available for Kanban boards in Jira.
• The Control Chart shows the Cycle Time (or Lead Time) for the issues on your board. It
takes the time spent by each issue in a particular status (or statuses) and maps it
over a specified period.
• The average, rolling average, and standard deviation for this data are shown.
• A Control Chart helps you identify whether data from the selected timeframe can be
used to determine future performance. The less variance in the cycle time of an issue,
the higher the confidence in using the mean (or median) as an indication of future
performance.
• You can use the Chart to analyze past performance in a retrospective and set targets
for your team, or provide stakeholders visibility into your team's performance
• Or measure the effect of a process change on your team's productivity
Let’s review this sample Control Chart.
1. On the lower left, you can choose one of the predefined timeframes – such as past
week, past month, past 3 months, etc. – or choose your own custom range. All the
calculations (average , median, etc.) will be performed on the set of data from your
selected timeframe.
2. On the lower right, you can refine the report by selecting fewer or more columns, or
swimlanes or quick filters. For example, let’s say that this chart shows the average for
all issues on the board, but you only want to see the cycle time for issues where the
Priority is Blocker or Critical. You can create a quick filter to show only those issues
and then use it to refine the report.
3. The narrower the standard deviation (the light blue shaded area), the better the
predictability of cycle time. You want to aim to narrow the standard deviation
through process improvements.
4. Here, we see a decreasing rolling average which indicates a process improvement
and increased throughput.
5. Outlier issues are those which fall far outside the average cycle time and standard
deviation, such as this one at the top. You can click on the dot to see the issue details.
You may wish to investigate the cause to reduce such issues in the future.
Now let’s look at Dashboards.
• Dashboards are a way to present a customized view of projects.
• They can be created for personal use or to share with others on the team.
• They are made up of one or more gadgets
• which can be presented in a customized layout
• There are many native gadgets to display some aspect of the work of the projects. We
will look at 4 which are specifically related to agile projects.
The Days Remaining in Sprint Gadget displays exactly that. Here, 22 days are remaining
• in Sprint 6
• On the board called “Scrum: Teams in Space”
The Sprint Burndown Gadget shows the information that you would find on the
Burndown Chart, except for the detailed table in the bottom part of the report – that
includes information such as scope changes.
• But you can clearly see scope changes in the chart shown.
The Sprint Health Gadget is a visual snapshot of the health of a sprint and has lots of
useful information.
And finally, there is an Agile Wallboard Gadget which displays
• a Kanban board
• or the Active Sprints of a Scrum board as a Wallboard gadget. You can see the issues
and the status columns they are in, but you cannot drag-and-drop them from the
gadget.
You can also display any dashboard in a wallboard friendly manner to be shown on a TV
in a room. This acts as an information radiator for the team improving the teams shared
understanding of the projects.
Hakeem says, “The product owner approved five new stories to include in our current
sprint. How will this impact our commitment? And will changing our estimation settings
be helpful in the future?”

To answer these questions. We need to analyze a few reports and inspect our board
settings.
In short, Hakeem should first check his current Estimation Statistic. Then go to the
Burndown Chart, Burnup Chart, Sprint Report, and Velocity chart to see whether there is a
chance he can still keep the commitment. In the PDF solution, we assume the current
Estimation Statistic is Issue Count, and that it would therefore be better for Hakeem’s
team to switch to using Story Points as the estimation method. Story Points are a
measure of the relative size and complexity of stories, which is a better indicator of the
real effort required and the chances of completing it, before and after the scope changes.

Also, the scope changes may have a larger impact than just the current sprint. For
example, due to the scope changes, they may not be able to complete other issues they
have already committed to. Those issues may have been a part of one or more epics, and
therefore impact the Epic Burndown. Or they may have been planned to a Version, in
which case there may be an impact to the Release Burndown and the Predicted Release
Date on the Version Report. It’s a good idea to review those reports, too. The PDF
solution guide also suggests creating some mock sprints to see how the reports appear
after the change to Story Points.
Evaluate the Epic Burndown Chart shown. Select two statements that are definitely true.
(Choose two.)

A. The team met each of their sprint commitments.

B. There were no scope changes during the sprints.
C. The epic will be done after 3 more sprints.
D. No estimated issues have been added to the epic.
E. 3 of the epic’s issues were completed in Sprint 1.
F. Each sprint may have included other issues.
Let’s review each option to see why it is correct or incorrect. The word “definitely” is
crucial to this question and to the answers.

A. Incorrect. We do not have a full picture about each of those three completed sprints.
In this chart, we only see the Story Points that were completed and those still
remaining on the issues that are contained in this epic only. So there is nothing we
can definitely say about the entire sprint commitment.

B. Incorrect. For the exact same reason as above, we do not know if there were or were
not scope changes in those sprints because we do not see all the other issues.

C. Incorrect. We do see that there are 3 estimated sprints to finish the rest of the issues
in this epic based on the completion rate of the first 3 sprints. However, anything
could happen. This is just a forecast, not a reality. So the statement is not definitely
correct.
D. Correct. Finally, this statement is well constrained. We do not see any dark blue plus
portions on any of the sprint bars. So no estimated issues have been added to the
epic. Unestimated issues, on the other hand, may have been added. They wouldn’t
register on the chart because it displays Story Points. But the statement doesn’t
mention those.

E. Incorrect. The chart shows burndown in terms of Story Points, not issues. We see that
in Sprint 1, 3 story points were completed. But this could have been 3 issues (each
worth 1 Story Point) or 2 issues (1 worth 1 point and the other worth 2 points) or 1 issue
(worth 3 points). So the statement is not definitely correct.
F. Correct. Based on what we already learned above, we can confidently agree that
each sprint may have included other issues, which were not part of this epic. The
words “may have” is what makes this statement definitely correct.

Yes, this question may seem difficult but close reading and careful analysis pays off in
finding the right answers.
In this final module, we will look at board caveats – which are some miscellaneous
concepts related to boards. Also, a quick look at a few typical issues related to board
configuration, their causes and their fixes.
There are two concepts that relate to prioritizing: priority and rank.
• The priority is a broader concept. It’s a system field with values like blocker, major,
minor, critical and it is set through the Issue Detail View
• Many issues will have the same Priority
• Rank is strictly positional. Each individual issue has a rank that corresponds to its
position on the board. The issues of the utmost importance should be at the top of the
backlog for easier sprint planning.
• You can rank by using drag-and-drop within the backlog or active sprints or Kanban
board. And you can also right-click a card on the board and choose a rank like “Top of
Sprint” or “Bottom of Backlog”
• Ranking requires the "Schedule issue" permission and the "Edit issue" permission in all
the projects on the board and the board filter must be ordered by Rank.
• And keep in mind that ranking is global so moving an issue up and down on a board
will affect its position on all the boards where the issue appears
• There are two levels of issue types in Jira. Standard issue types, including Epic, Story,
Task, Bug
• And sub-task issue types, like sub-task or custom ones like dev-task
• Standard issues like Stories and Tasks can (but don’t have to) contain one or more sub-
tasks
• Epics are also standard issue types from a purely Jira administrative perspective, and
as such they can also have their own sub-tasks, though this is not as common in agile
practice and projects
• But epics are unique. They have a bigger scope than the other standard issue types.
They can contain the other standard issue types (stories, tasks, bugs, etc.), and those
contain subtasks.
• So, in essence, all this functions like a 3-level hierarchy in terms of relationship. The 3-
level issue-type relationship is used extensively in agile projects and has a lot of
implications for how issue types appear and function in issues and boards.
• In Scrum boards, epics always display in a dedicated Epics Panel in the Scrum Backlog.
• In Kanban boards epics display in the main Kanban board by default but can
optionally display in the Backlog, if the Kanban Backlog and the Epics Panel settings
are both enabled.
• While the other issue types like stories are planned and completed within a sprint, an
epic will usually span many sprints because child issues of an epic can span multiple
sprints.
• You can associate issues to epics from across multiple projects, teams, and boards.
For example, epic MIRO-1 can be linked to story DEV-2 and task ENG-3, using drag-
and-drop, if all three are located on the same board
• If you view an issue belonging to an epic, you will see the epic in the Epic Link field and
can then click on the link to view the epic. When you are creating issues that will be
children of the Epic you can use the Epic Link Field to select the parent Epic. The Epic
Link field is used widely for searching issues associated with the epic, sorting issues
into swimlanes by epic, filtering boards by epic and just displaying the name of the
epic on cards.
• The Epics panel is used to monitor the current status of the epic; for example, you can
see how many of the issues have been completed.
• To create a new issue and associate it with an epic, you can do it right in the backlog
using the “Create issue in epic” link. Of course, you can also create an epic from the
Create button in the main navigation bar.
• To associate existing issues with an epic on the board, you can use drag-and-drop.
• Epics will appear in the panel until you select “Mark as Done” from the dropdown next
to the epic name in the Epics panel. This changes the Epic Status field of an epic to
Done and removes the epic from the Epic Panel. This is different than setting the
workflow status of the epic issue to Done (for example by dragging the issue to the
Done column).
• As a best practice to avoid confusion, you may want to set the epic issue’s status to
Done at the same time that you select Mark as Done in the epics panel.
• The Versions Panel exists on Scrum boards only.
• It lists all the unreleased versions in the project, or projects, on the board. Hence, you
must release the Version to drop it out of the Versions panel
• The panel helps monitor the status of versions
• Create issues in a Version or use drag-and-drop to associate existing issues
• But you can only associate issues to versions from their own project, not across
projects. So, if a board contains issues from ENG and DEV projects, you can associate
ENG issues only with Versions from the ENG project. And the same for DEV. You cannot
associate an ENG issue with a Version from the DEV project.
• As we learned earlier, boards display the issues returned by their underlying board
filter. Hence boards can, and often do, include issues from across multiple projects.
This is a source of confusion to many users who are unaware of all the caveats and
implications of such a complex setup.
• As we just learned, you can associate an issue from the DEV project with an ENG epic.
But you cannot do the same with Versions even though those other fix versions – from
other projects – are shown in the version panel on the board.
• Boards respect all schemes of all projects in the board (for example workflow and
permission schemes). So, while you may be able to transition from In Progress to Done
in one project, there may be a workflow condition in another project that prevents you
from doing the same. Similarly for permission schemes. You may be able to Delete
Comments or Attachments in one project but not another.
• When you complete a sprint, all the issues move out of the Active Sprints board.
• If the issues are completed, they are removed from the board, but continue to be
visible in reports.
• Any issues not completed at the end of the sprint will be moved to the next planned
sprint, as they did not meet the team’s “Definition of Done". If you do not have a next
planned sprint, they will be returned to the backlog and will remain visible in the
board.
• Parent issue and all sub-tasks must be Done in order to be considered complete. So, if
you have parent issues that are not Done – even though all their sub-tasks may be
Done – the parent issues will still be moved to the next sprint/backlog. If these parent
issues are part of another active sprint, the previously completed sub-tasks will still be
Done.
It’s good to know several sprint-related JQL functions.
• openSprints() : finds issues that are assigned to a sprint that was started but has not
yet been completed.
• closedSprints() : finds issues that are assigned to a completed Sprint.
• futureSprints() : finds issues that are assigned to a sprint that hasn't been started yet.
And note that the correct syntax uses the sprint field.
• Also, it is possible for an issue to belong to both a completed sprint(s) and an
incomplete sprint(s); either a current/active sprint or a planned/future sprint.
• And – if there are are no other clauses in the JQL query – then these functions find
issues in all sprints in all teams / projects.
Now let’s have a quick look at a few issues related to board configuration, their causes
and their fixes.

I can’t see some issues on my Scrum board. Why?

Check the board filter
• Is it returning the expected issues? The filter query might only be displaying issues
based on Labels, components, or some other criteria which excludes the issues you are
expecting to see. You may need to update the filter.
Check issue status
• Are the Stories already done? Issues in completed sprints will no longer show on the
board but they will show in reports. And the backlog does not show Done issues.
Check issue type
• Are you looking for sub-tasks in the Backlog? Remember the backlog only shows
standard issue types. Sub-tasks can be seen in the issue detail view.
Check Columns configuration
• Are there unmapped statuses? If yes, then you won’t see the issues displayed on the
board until you map the statuses.
Consider other reasons
• For example, does the project use issue-level security? If so, you won’t be able to see
secured issues anywhere in Jira, including boards, unless you are listed in the issue’s
Security Level.
I can’t see some issues on my Kanban board. Why?
Just like in Scrum boards, you should check the board filter, unmapped statuses, and
other miscellaneous reasons. But there could be two other board configurations
responsible, which are specific to Kanban boards.

Check released issues

• Are the missing issues already Done and released from the board? Remember that
the default Kanban sub-filter excludes issues in released versions. So, if the issues
have already been released, they will not display in the Done column.

Check the Kanban sub-filter

• But perhaps the Kanban sub-filter was updated with another JQL query. Could that
query be excluding the issues?
I can’t rank issues on my board. Why?
Check the board filter query.
• Is it using Rank?

Check project permissions.

• Do you have both Schedule Issues and Edit Issues permissions in all the board’s
projects?
• Did you check all the projects? If there are multiple projects displaying issues on the
board, you need to have both permissions in all their permissions schemes in order to
Rank issues.
I don’t see all my Epics in the Epics Panel. Why?
Check the “Epic Status” field.
• Is “Epic Status” set to Done? That is what happens when Epics are Marked as Done –
from the dropdown next to the epic name in the Epics panel. It is the value of Epic
Status – not the workflow status – that determines if Epics show in the Epics Panel.

Also check the board filter.

• Does the JQL query include the epics in question?
My swimlanes are ordered by Epics. But I don’t see all the epics and the ones I do see are
not in the right order. Why?
Check the issues in the Epics.
• Do the Epics have any issues? Epics with no issues on the board will not be shown as
swimlanes.

Check the Epics Panel.

• Are the Epics ranked correctly in the Epics Panel? You can drag-and-drop Epics to
reorder them. The swimlanes will then respect the order.
I see versions from other projects in my Versions Panel. But I can’t drag-and-drop issues
into all of the versions. Why?
Check the board filter.
• Does it display issues from multiple projects? If yes, then all unreleased versions from
all the projects on the board will be displayed in the Versions Panel.

Check the version you’re associating.

• Remember that you can only associate issues to versions in their own project, not
across projects.
Some cards are assigned the wrong card color. Why?
Check the configuration of Card colors in Board settings.
• Which method is being used to assign colors to your cards? For example, Priorities.
• Is that what you intended? Is the right color assigned to the right priority value?
• Do the cards have the expected value? Do the issues have the priorities you expected?

Check the JQL

• If you’re using JQL queries, is the JQL correct? Did you use the right Boolean operators
and add parentheses?
• Does the JQL return the expected results when run in the Issue Navigator?

Check the order of queries

• Is it correct? Remember that issues will be assigned to the first card color where the
query matches.
Some users can’t transition issues on my board. Why?
Check project permissions
• Do the users have Transition Issues permission?

Check the workflow

• If it’s not a Simplified Workflow, it’s possible that there are workflow conditions
preventing some users from transitioning.

Check the configuration of columns

• Perhaps the users are trying to transition into an unmapped status or
• trying to drag-and-drop between two statuses in the same column. Remember that
this is not possible from the board but only from the issue.
In this use case, we will help Tara troubleshoot and fix some problems with a board she
created and configured.

• No one can see it

• She can’t rank issues
• She sees Epics that have long been completed
• Issues appear in the wrong swimlanes

We need to evaluate the root cause and find the appropriate solutions.
Each of the problems has one or more possible causes and solutions. They are listed here
briefly but you can refer to the PDF guide for the detailed explanations.

1. The fact that no one can see the filter is probably because she has not shared it with
anyone or with the right people.
2. She might not be able to rank (1) either because ranking is disabled in the query or (2)
because she doesn’t have the necessary Schedule Issues and Edit Issues permissions.
3. The epics in question may have a workflow status of Done (or Closed, Resolved, etc.)
but they will continue to appear in the Epics Panel until they are Marked as Done.
4. If swimlanes by queries are not working properly, it could be that (1) they are in the
wrong order or (2) that one or more of the queries is returning the wrong results. You
can use the Issue Navigator to test and correct the JQL.
This final knowledge check is a good example of assimilating a lot of knowledge – about
boards but also about Jira in general. This gives you an idea of the kind of questions that
appear on Atlassian certification exams where you are not told which module a
particular question comes from. You must be able to analyze and evaluate the answers
on their own merit, based on your knowledge and experience. So get ready.

Mike’s Scrum board contains issues from two projects: ACME and BREA. Which action can
definitely be performed on his board?

A. drop ACME issues into BREA versions

B. release ACME issues from the Done column
C. estimate ACME issues with Story Points and BREA issues with Business Value
D. create ACME sub-tasks under BREA stories
E. drop ACME and BREA issues into any board column
F. mark either ACME and BREA epics as Done
F is correct. Let’s go through the options.

A. Incorrect. Issues can only be associated to versions in their own project. Hence, ACME
issues can be dropped into ACME versions, but not BREA versions/
B. Incorrect. The release functionality is only available on Kanban boards. Mike’s is a
Scrum board so you cannot release any issues from the Done column
C. Incorrect. A board uses a single estimation statistic. So, you could only use Story
Points or Business Value for both projects.
D. Incorrect. Parent and child issues always reside in the same project. Therefore, BREA
sub-tasks can only be created under BREA stories.
E. Incorrect. While it may be possible to drop ACME and BREA issues into any column,
we cannot say that this is “definitely” the case. Because we do not know enough
about the workflow(s) and the board configuration. We have seen this nuance before.
The word “definitely” is crucial to eliminating this option.
F. Correct. The “Mark as Done” functionality is available for any epic that appears in the
Epics panel on a board, so either ACME or BREA epics can be marked as done.
• The board type – Scrum or Kanban – determines the available functionality and reports
in a Jira board.
• Each board can have its own complex configuration
• The board filter determines the issues displayed on the board – which can come from
multiple teams, multiple projects and project types.
• Agile reports help monitor the progress of sprints, epics, and releases, control the
burndown rate, identify problems and bottlenecks, and continuously improve velocity
and cycle time.
Congratulations on completing this course!
We hope you enjoyed this course and learned useful things that will help you in your
daily job as Jira project administrator.

Fur further information, visit our online resources including Atlassian University, Atlassian
Community and Atlassian's product documentation.

For more in-depth help, contact Atlassian Support or locate one of the Atlassian Solution
Partners near you.