Find the companion video here.
The first kind of tool we want to talk in the tool chapter of the Summer Academy is issue tracking systems. We see the three major advantages of a tracking system: First, collecting the issues in a structured way. Secondly, forcing and tracking a process. And lastly, providing the opportunity for release planning, retrospective, and BI.
Simply put: All issues should be handled through an issue tracking process using an issue tracking system. Reject to address any issue not captured within the issue tracking! For persons who cannot (or too senior to be asked :-) ) file a report, offer to do it for them. Make sure all those who should be able to report an issue are well aware of the process and know the rules of the game.
Getting hold of an issue tracking system is not that hard. GitHub and GitLab provide basic functionality. Lots of teams use JIRA and there are open-source alternatives such as Bugzilla, Launchpad, OTRS, Redmine, or Trac.
A good issue report is actually harder done than said. Here are some best practices for good issue reports:
|Field||Comment||Bad Example||Good Example|
|Title||Short and Precise Summary||“App freezes”||“App freezes when network connection is lost during splash screen”|
|Severity||Instead of asking the reporter to assign a severity, have a heuristics||“7 - Medium to High Severe”||“1026”|
|Affected Stakeholders||Customer, reporter, DevOps…||“Reported by Anonymous”||“Reported by XYZ (USD500k customer)”|
|How to reproduce||Following the SSCCE ideal||“App freezes”||“Starting App and logging in as Worker, navigating to Data Entry form using dashboard navigation, new form, entering 2000 in value, clicking OK, app freezes”|
|Environment||For reproduction purposes, find balance between too few and too much data which annoys reporters, provide automatic or easy to read data points such as version numbers or system IDs. Too many data points produce also noise for the developer and simply distract||“Mobile phone”||“One+ 7 pro, fresh reboot, no other app running, WLAN access”|
Regarding the severity heuristics:
We would assign a weight following these lines (from high to low):
You might want to ask for possible security breaches (always highest severity!!!) or customer data loss, reduced availability, reduced performance, etc. You can multiply by a weight factor given by the number of impacted customers or the importance of the customer, the age of the report, etc. Taking the age into account also resolves the issue of reports falling through and effectively never being looked at. Assign numbers on a spectrum that makes it unlikely that they will overlap so you can easily sort by this number and start to work from the top during the triage.
Affected Shareholders are interesting to understand the extent of the issue as well as whom to keep informed about the process, ask for further details, or to test possible fixes.
There might be the need for an Expedited Bug Process to address the immediate danger to top goals like safety or security
If you do your Issue Tracking well, the data can be a treasure trove. But be aware: Garbage in, garbage out. Make sure the data quality is good. Always prefer automatic data over manual entry, because it is an additional burden and most of the time, the quality degrades over time.
Issue tracking is essential. Make sure to have a rigid format and process at hand. Use heuristics to reduce subjectively (and sometimes hard) decisions.