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.
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 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 read 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.
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 your product's quality. 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 that 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 easier.
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.
Let’s Recap!
Working in a collaborative and “agile” manner should lead to:
Increased trust between the developers and the stakeholders.
Increased clarity on that 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 easier.
It's ok for a team will make mistakes. You need to focus on why we are making mistakes, are we learning from our mistakes and how can we improve as a team to make less 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.
