This lesson provides insight into how issues reported via ZenDesk are addressed and different factors that effect a resolution.
Bug Prioritization FAQ
What is bug prioritization?
In software development the term “bug” means a flaw or fault in the design, development, or operation of computer software that causes it to produce an incorrect or unexpected result, or to behave in unintended ways (Wikipedia).
Illuminate Education strives for the highest level of quality in its software releases. We have manual and automated testing and review processes to find and fix bugs before they’re released so that we can provide our customers with a seamless and bug-free user experience. Unfortunately, some bugs escape detection.
Whenever a client contacts Illuminate with a bug they have discovered, it is routed through our Customer Support group. Their job is to gather as much information as possible about what caused the bug to reveal itself, because details matter as we work to reproduce and fix the bug as quickly as possible. Our Support team may ask a lot of questions!
You can expect Support to ask questions about the operating system, network speed, and other 3rd-party elements such as student information systems, APIs, and firewalls. They will also ask for any additional circumstances such as what the user was trying to do, what was specifically clicked on, and whether any recent system changes occurred (screenshots are especially helpful). Finally, they will ask what kind of impact this bug has had on the user’s work. For more information, please refer to Contacting Support.
The Support team then uses their product expertise and additional back-end tools to try to recreate the issue and find the bug. All of these details are logged in our project management system, and then sent to the Product team for further evaluation and tracking.
The Product team then reviews the bug and begins the hard work of prioritizing it among all other work taking place.
Some bugs are relatively benign, while others can have a significant impact on many customers at once. Product and engineering teams need to take many variables into consideration to understand the impact and scope of the bug before beginning work. Our top goal is minimizing disruption to customers while maximizing functionality and usability, balancing trade-offs between fixing bugs and developing important new features. Carefully and accurately determining priorities is very important. This means that some bugs will be prioritized higher than others.
Think of prioritization like a hospital’s Urgent Care center, where the context of each patient’s unique situation is key. For example, a broken arm is a serious injury that probably requires more attention than a bad cut; however, if there’s been a car accident, even a broken arm might
be put aside to assess and treat the car accident victims. Triage depends on all the moving pieces at any given time.
In bug prioritization product teams need to balance customer disruptionslarge and smallwith ongoing efforts around platform security and architecture, development priorities, contractual deadlines, and more.
For this reason, it’s important to offer a complete picture of how a bug is impacting your work, including any time dependencies or important state or district deadlines on the horizon. Helping our Product team understand your situation is critical to their ability to accurately prioritize the bug, pinpoint and triage the issue, and resolve as many bugs as we can, as quickly as possible.
How do we review bugs?
We review bugs through an ongoing, cross-department triage process, as well as a number of internal escalation pathways. Broadly speaking, bugs tend to fall into high- and low-priority issues.
- High-priority issues include things like system operability and accessibility of core data and functionality.
- Low-priority issues include bugs with limited impact on minor functionality or non-critical data with a low potential for service disruption, the existence of easy workarounds, and cosmetic issues.
In addition, we work to understand each bug’s specific impact on individual customers as well as the number of customers impacted by a bug.
How long will it take to fix a bug?
Timelines for fixing bugs are difficult to determine, given the interrelated nature of multiple work streams. Critical high-priority issues can result in Product teams dropping everything in order to devote all of their attention to an urgent and important issue, which can result in other delays. Lower priority issues can take much longer to fix depending on a number of factors, including the urgency of any other bugs already on the radar, the complexity of engineering required to address the bug, and the time of year. (Because back-to-school and school year rollover time frames are extremely busy for our customers, they're also busier for us as our teams work to support a variety of time-sensitive client needs.)
How will I know the status of my bug?
We are implementing a new process through which you will be told if your reported bug generally qualifies as a high- or a low-priority issue. For higher priority issues, we will keep you updated as bugs move through the development queue. For lower priority issues, we will check on your issue every month and provide updates on its status as we monitor bug traffic. Any time a bug moves forward into a development phase, we will alert you. In those instances where we determine we will not be able to fix a bug, we will inform you of that decision as soon as possible.
Can Priority Levels Change?
Many factors influence priority levels, meaning that priority is a relative categorization that’s constantly in flux. Things like the urgency of any other bugs already on the radar, the complexity of engineering required to address the bug, and the time of year can all impact priority. For that reason, the priority level of any issue may change to a higher or lower position. Our goal is always to minimize disruption and to maintain full system access to our customers. Customers will always be notified if the priority level of a bug that you’ve submitted changes.