Getting Started with Jira
In the last chapter, you learned that a good bug report contains the following elements:
Steps to reproduce
Device and OS
Links
Expected behavior
Actual behavior
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.
If you don't have a Confluence account, you can go directly to the Jira page website to create one.
Next, create your account with your email.
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.
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".
And finally, select "Team Managed" as the organization:
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.
Create an Issue
To create an issue, go to your backlog accessible on the left-hand menu:
When you click on “Create”, a pop-up appears where you can add details of the 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).
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.
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.
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!
