• 10 hours
  • Medium

Free online content available in this course.

course.header.alt.is_video

course.header.alt.is_certifying

Got it!

Last updated on 9/9/24

Learn How to Use Jira

 

Getting Started with Jira

In the last chapter, you learned that a good bug report contains the following elements:

  1. Steps to reproduce

  2. Device and OS

  3. Links

  4. Expected behavior

  5. Actual behavior

  6. Screenshots

JIRA, a product of Atlassian (the makers of Confluence), is a top-rated tool used by teams worldwide. Initially created for software development. JIRA, and tools like it, are used in various industries and departments to visualize work, track bugs, manage service desks, and develop solutions to complex problems.

Create a JIRA account

If you made a Confluence account before, you have an Atlassian account and can use the free account to access Jira in Atlassian apps. If not, you'll need to create an Atlassian account first. You can follow the steps in the chapter here

Go to your Confluence account to get started. The Atlassian apps can be accessed via the button in the top left-hand corner: click on Jira Software.

From the Confluence account, you can choose Atalassian Start, Jira Software, Jira Work Management, Confluence or Administration. Here we click on Jira Software.
You can acces Jira from your Confluence account

If you don't have a Confluence account, you can go directly to the Jira page website to create one.

A screenshot of the Jira homepage, inviting you to get Jira for free.
The Jira homepage

Next, create your account with your email.

A screenshot of where you can enter your email to create an account.
Enter your email to create an account

Set Up Your First Jira project

Once your account has been created, you'll be taken to a page where you'll be asked to create a project.

A screenshot of the message that appears when you don't have any projects. There is a button to Create a project.
This message appears when you don't have any projects

Jira offers different types of templates project organization (Scrum, maintenance, marketing...) depending on the workflow and type of work you do. Most teams use the Scrum template, which features a backlog, kanban board and other options. Let's use this template for your first project. You can find it in "Software development" → "Scrum".

From the software development page, choose the Scrum template to create your first project. We also see the possiblity to choose Kanban or top level planning.
Choose the Scrum template to create your first project

And finally, select "Team Managed" as the organization:

When prompted,  you can choose Team Managed for your first Jira project by clicking on Selct a team-managed project.
Choose Team Managed for your first Jira project

You should end up with the project details that you see below. Add a name and a key: the key should fill in automatically depending on the name you enter. This key will serve as an identifier for user stories, bugs and epics.

The project details include the Name and the Key.
Here is where you can add project details

Create an Issue

To create an issue, go to your backlog accessible on the left-hand menu:

In your project you will see Backlog in the vertical menu on the left side of the page.
The Backlog

When you click on “Create”, a pop-up appears where you can add details of the issue:

The pop-up enables you to define an issue type, such as bug, story, task, epic. and then add a short summary and a more complete description in the dedicated fields. The issue can then be assigned to someone automatically or manually.
Creating an issue

Identify Issue Types

JIRA has many configuration options so that different engineering teams can set up their environment to match their workflow. If your team is using JIRA, you might see different options depending on your team's configuration.

Many organizations would like you to create one JIRA issue per bug. Usually, they will encourage you to link this bug to another work item that created it, is related to it, or helps in some way to understand quality concerns in the product. Note that issues can have several types, but you should create an issue of type Bug for reporting bugs (where something doesn't work as expected).

The 6 Jira Issue Types: New feature, task, improvement, bug, story and epic
JIRA issue types

Assign Statuses on JIRA

Let's think through a theoretical lifecycle of a bug/issue:

  • Monday - The product manager notices something is broken and creates a bug issue type in JIRA.

  • Tuesday - One of the developers finishes a task, checks JIRA, and sees that this bug needs to be worked on.

  • Wednesday - After spending one day on the problem, the developer finally fixed the issue just before lunchtime.

  • Thursday - The product manager sees that the bug is fixed and tests it. Great news! The fix is perfect, and the system's behavior is now ideal.

  • Friday - As luck would have it, there is a release today, and this bug fix is part of that release! Customers will no longer see this issue.

Then the status of this JIRA issue would change during the week:

  • Monday - Just after creation, the issue is TO DO.

  • Tuesday - As soon as the developer investigates, she sets the status to IN PROGRESS.

  • Wednesday - The developer finishes fixing this issue and sets the status to READY TO TEST.

  • Thursday - The product manager sees this item is ready to test and then does so. Everything is perfect, so they set the status to DONE.

  • Friday - After the release goes out with this fix, the product manager (or engineering manager) sets the status to IN PRODUCTION.

The 5 Jira Statuses: to do, in progress, ready to test , done and in production.
JIRA statuses

Statuses are essential because team members know what issue to work on depending on its status. In particular:

  • An engineer knows they can work on a to-do issue. 

  • A product manager knows they can test a ready to test item. 

  • An engineer knows that testing went well on a done item. 

  • In production shows that the customer won't have an issue. 

There are many other statuses, although those above are the main ones. Some others are worth mentioning:

Set a Priority

When you create an issue, you can set a priority.

  • An existing feature (that customers use and depend on every day) that breaks is the biggest priority. That's as bad as things can be. The customer is trying to achieve some outcome or perform a task they have done many times, but they are blocked. That is the highest priority!

  • A problem that could potentially block progress is a high priority.

  • Something that you can easily work around is a low-priority item. 

JIRA priority levels from Highest to Lowest. Highest - the problem will block progress- High - it could block progress, Medium -may affect progress, Low -minor or easily worked around, Lowest - trivial with little or no impact on progress.
JIRA priority levels 

Avoid The Blame Game

When you build products, mistakes will happen. If these mistakes make it into the product, some teams may call these bugs, defects, or other terms. However, regardless of what you call them or how you approach them, learning from them is critical for long-term success.

As a product manager, don't blame the team if mistakes happen. Instead, pay attention to patterns that emerge. Do you see the same mistakes? Is the product full of many small bugs? A few huge ones? It's important to always stay on top of the quality of your product. It helps you decide how best to order your backlog and what expectations to set with partners and customers. A primary duty of a product manager is whether to encourage the team to increase quality (fix bugs) or continue to develop the product (new features) - or both.

Just as an example, you might find that more bugs happen when:

  • The team moves more quickly.

  • There are pressing deadlines.

  • New features take priority over clean code.

  • The team expanded very quickly. 

So never play the blame game. Rather ask "why" if it seems like there are too many bugs. And ask if you can help. The answer is always that you can.

Final Thought on Communication

The details of how you create a feature or user story are very important. Getting all team members involved from the start is the key to understanding what it takes to deliver value to customers.

Developing user stories and acceptance tests during requirements workshops are the best way to develop shared knowledge. In addition, storing these details in a wiki will make collaborating and keeping things up to date easier.

The Agile Manifesto is a tool to support communication and collaboration.

Individuals and interactions over processes and tools mean having discussions rather than inputting requirements into a document, piece of software, or similar tool.

Customer collaboration over contract negotiation encourages sitting down with a customer, stakeholder, or product user to find solutions to their problems and needs versus writing contracts and only delivering what they ask for.  

The tech team's user stories and acceptance tests are the foundation of product features. But the conversations within the group will determine your success!

Shared understanding is the ability of multiple agents to exploit common bodies of causal knowledge to accomplish common (or shared) goals.

A key tenet of agility, as codified in the Agile Manifesto, is that people need to work together.  This idea of collaboration is mentioned in many different ways but it doesn’t tell us exactly how to do it.  This is where we have freedom to work in any manner that we’d like as long as we keep the intent and values in mind.  In my experience, working in a collaborative and “agile” manner will normally lead to:

  • Increased trust between the developers and the stakeholders.

  • Increased clarity on the current state of the work for the product or project.

  • Decreased time spent in low value meetings and status update activities.

  • Higher quality and a higher likelihood of producing valuable outcomes for the company and the customers.

  • Improved job satisfaction as the team can connect their work to a common purpose much more easily.

An agile team that works together better understands how to meet goals. This is related to transparency in empiricism. Transparency is not just about making something visible but increasing its shared understanding.

Your turn!

A new bug has been detected in the quiz. Normally, when the student fails the quiz three times, they have to wait 24 hours to take it again. It seems that there's a bug on the site that allows the student to retake the quiz straight away.

Use what you have learned here, and in the last chapter, to write the bug report in Jira.  Remember to be thorough so that the developers can correct the problem!

When you've finished, check out this bug report to compare your work! 

Let’s Recap!

  • It's ok for a team to make mistakes. You need to focus on why mistake have been made, what can be learned from mistakes and how we can improve as a team to make fewer mistakes in the future.

  • Agility is about changing from individual work and individual success or failure to a culture of team-owned work and team success or failure.  

  • The Agile Manifesto contains four values and twelve principles that are all valuable. 

Congratulations! You’re almost finished. Take the last quiz to reach the end of the course! 

Ever considered an OpenClassrooms diploma?
  • Up to 100% of your training program funded
  • Flexible start date
  • Career-focused projects
  • Individual mentoring
Find the training program and funding option that suits you best
Example of certificate of achievement
Example of certificate of achievement