Many people are surprised about what's involved in maintaining a custom software application (what we call our Voyage service at Airship). We like to define software maintenance as a partnership to continuously improve an application - from repairing broken functionality and building feature enhancements to user testing and finding new opportunities for improvements.

And like any partnership, effective communication is key.

We find it helpful for everyone to be on the same page and speaking the same language when dealing with critical issues and prioritizing work for our clients. Would you want changing a button color to have the same urgency as fixing a crashed app? Both can be considered important, but one has a more direct and immediate impact on your business.

That's why we wanted to share how we define and categorize application issues according to 5 severity levels with examples. Each level tells us how urgent a task is and how it needs to be prioritized - and it helps our clients be prepared to answer questions and provide details.

1. Blocker - Severity Level 1

With any application, bugs and errors happen over time and with continued use. Third-party apps break, servers slow to a crawl, programming languages malfunction, major updates are released on mobile devices, users are requesting a tablet-compatible app, etc. Breakdowns in code are bound to happen no matter if it's a careless error or an act of God.

Issues at the Blocker Level are the threat-level-red, emergency-to-take-care-of-ASAP incidents. The kind that need to be communicated and addressed immediately by a team member. This level of severity is reserved for the most urgent of issues.

So what does a serious issue look like for your product? The production application is down or a major malfunction pushes your product to an inoperative condition. Users are unable to reasonably perform their normal functions. This level of severity requires emergency response immediately.

Too panicked to realize what's going on? If this seems familiar, you're at Level #1.

AHHHHHH. Help! Everything is down! We are losing customers as we speak!!!


via GIPHY

2. High - Severity Level 2

High severity issues involve critical loss of application functionality, such as a high number of users unable to perform their normal functions. These are major feature and product failures where an inconvenient workaround or no workaround exists.

The key difference with High severity issues is that the program is usable, but severely limited.

I would LOVE for this area of the app to improve off of some recent feedback about difficult navigation. How can we do that?

We've had several android users reporting problems.

via GIPHY

3. Medium - Moderate Severity

Medium severity issues involve moderate loss of application functionality or performance resulting in multiple users impacted in their normal functions.

Your program is still usable and isn't severely limited, but the issue could cause more severe problems and poor feedback down the line if not addressed soon.

Lets speed up the app!

We are getting several reports of users not receiving the welcome email. Can we look into this?

via GIPHY

4. Low - Minor Impact

Low severity issues include minor feature or product failures. This means that a convenient workaround exists for users. There's some minor performance degradation, but it is not impacting production.

These issues are improvements you want to make that can help your users, but its potential to cause serious problems is low.

I wish this page’s scroll was a little bit smoother so it was easier to read through.

The contact us link is not working properly, but we do not get a ton of feedback from users in this way since they still have our email and contact information.

via GIPHY

5. Lowest - Little-to-Zero Severity

It's called Lowest for a reason! Lowest severity issues are strictly cosmetic in nature or have little impact to functional use of the system.

These issues are resolved only after higher priority issues are fixed first.

Lets make this quick color change to this feature

via GIPHY

Conclusion

Remember, bugs and enhancements are a normal part of software development and often give us opportunities to improve features and make them even better for your users!

As long as your team can speak the same language when it comes to critical issues, your team will be prepared to prioritize and find solutions.

Problem-Statement-Webinar-PDF-no-date

Start with: What problem are you trying to solve? 

One of the activities we work through revolves around refining your problem statement. A problem statement is the key business problem that needs to be solved. In software development, it states “what has to be done” for a project to succeed. It does not say, “how it has to be done.”

We use the 5W’s + 1 H format as well as the SMART Framework when establishing a problem statement. In fact, you can draft your own problem statement by using our free download. This download will get you thinking through some of the questions and answers prior to starting your project.

Download: Problem Statement
 
Ready to get started?