In the last lesson, we learned about the characteristics of a good bug report. We saw that a good bug report contained the following elements:
Steps to reproduce
Device and OS
JIRA is a very popular bug tracking software created by a company called Atlassian. This is the same company that makes Confluence (the wiki software that we used earlier in this course). Many people buy both JIRA and Confluence from Atlassian.
JIRA has many configuration options so that different engineering teams can set up their JIRA environment to match their workflow. This means that if your team is using JIRA, you might see different options depending on your team's configuration of JIRA.
You should be to create one JIRA issue per bug. Note that issues can have several types but for reporting bugs (where something doesn't work as expected), you should create an issue of the type 'Bug'.
Let's think through a theoretical life cycle of a bug/issue:
Monday - the Product Manager notices something is broken and creates an issue of the type 'bug' in JIRA.
Tuesday - one of the developers finishes a task and checks JIRA and sees that this bug needs to be worked on.
Wednesday - after spending one day on the problem, the developer finally fixes the issue just before lunch time.
Thursday - the product manager sees that the bug is fixed and tests the fix. Great news! The fix is perfect and the behavior of the system is now ideal.
Friday - as luck would have it, there is a release today and this bug fix is part of that release! Customers in the real world 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 starts to investigate, 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 tests it. Everything is perfect so the product manager sets the status to "DONE".
Friday - after the release goes out with this fix in it, the product manager (or engineering manager) sets the status to "IN PRODUCTION".
Status are important because members of the team know whether they should start working with this issue (or not) depending on its status. In particular:
An engineer knows that if an issue is in their current project space and is 'To Do' , then they can pick it up.
A product manager knows that if an item is 'Ready to Test', then they could test it.
An engineer knows that if an item is 'Done' then the testing went well.
Anybody can see that if an issue is 'In Production' then real customers don't have this issue.
When you create an issue, one option that you have is to set priority.
The biggest priority is that existing features (that customers use and depend on every day) are suddenly broken. That's as bad as things can be. The customer is trying to achieve some outcome or perform some task that they have done many times but they are blocked from doing so. That is the highest priority!
A problem that could potentially block progress in this way is a 'high' priority.
If something is easily worked around, then those are low priority items.
The Blame Game
When you build digital products, bugs will happen. Hopefully there aren't too many but there will be some. For exactly the same reason that talented authors need editors, the engineering team need their work to be reviewed (tested) by someone who isn't them. I'm sure you've noticed this before with a written document or email; when you write it, you need someone who hasn't written it to give you feedback!
So don't blame the tech team if bugs happen. If the same bugs keep repeating, then talk about that as a team. If the bug count is too high, then it is your role as a product manager to prioritize whether the team should increase quality (fix bugs) or continue to develop the product (new features).
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 is 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 a feature or user story work are really important. The process of getting all team members to participate in the evolution of what those details are is the key to the team having a shared understanding of what is required to deliver value to customers.
User stories and acceptance tests developed as a team in requirements workshops is the best way to develop that shared understanding. Storing these details in a wiki will facilitate easy collaboration and maintenance (i.e. keeping them up to date).
The Agile Manifesto has a beautiful way to express this:
Communication is an example of the difference between valuing individuals versus process
Within the tech team, the user stories and acceptance tests will form the basis for which product features are built. But the conversations within the team that flow from discussion of these user stories and acceptance test will determine your success!