Relationship among: Severity, Business Impact and Priority

I have been working in a QA department for more or less 2 years now. I have read a bit about it and it seems that the definitions of Severity and Priority are a little subjective and as a consequence, used with different purposes.

In my case, I add a third element in the group: the business impact, because sometimes your user may not be your client. For example, in a web like Infojobs or Emagister, the user searches for a job or course (navigates the site) and the clients are the companies or schools (who pay to be there)

From what I have been able to learn in practice on an online web company,

  • Severity: refers to the impact a defect has on the product itself from a user’s perspective. For example: a page not found (404 or 500 error); a user can’t login the application; a distorted layout; a non working functionality; etc. There are 4 levels:
  1. Severity 1: assigned to something that is stopping you like a critical functionalilty broken.
  2. Severity 2: when a non-critical functionality is broken.
  3. Severity 3: assigned to a minor error.
  4. Severity 4: something trivial like a copy or a cosmetic issue.
  • Business Impact: refers to the impact a defect has on our clients. For example: the logo of a client is not well seen; a missing field in a form; etc. The business impact can change in time as if the defect is not solved in a period of time, the noise it creates increases.
  • Priority: factor by which the bugs are ordered to make sure the more important ones are addressed first.

I use a formula like this:

x% Severity    x     y% business Impact = Priority

But as I said, the assignement of this values is very subjective and there are other factors to bear in mind, as for example:

-Have you found the defect on a staging environment or production? If it happens in stating, the business impact is lower as the client is not affected yet, so severity has a higher importance.

-A low severity-high business impact, is very complex to solve? Technical complexity is a factor that sometimes needs to be taken into account as you may not have time or resources to dedicate to it. In those cases it needs to be discussed among the Project Manager, the Scrum Master, the Client and/or sometimes the CTO.

It is very important that the Severity and Busines Impact is not given by the same person as it can tip the scales in ones favor.



Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de

Estás comentando usando tu cuenta de Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )


Conectando a %s

Blog de

Subir ↑

A %d blogueros les gusta esto: