Priority and Severity

All decent bug tracking and issue tracking tools will include a field in their bug report template for Priority and another field for Severity. These fields are used to describe the importance of a given bug by the person who is reporting it to the person who will eventually handle it.

The big question is this -what is difference between Priority and Severity? And which one should use when?

The image below should explain how to triage bugs (triage in a hospital is the process of determining the priority of patients’ treatments based on the severity of their condition).

However, for added detail, check out the bullet points below which should explain Priority and Severity even further. 

Priority:

• Priority relates to how fast the bug or issue has to be fixed.
• Priority is related to scheduling to resolve the problem.
• Is largely related to business or marketing considerations in that it is indicatory of the importance of the bug especially in terms of stakeholders.
• The priority status is also set based on the customer requirements.
• Priority relates heavily to the technical aspect of the product and how ‘bad’ the impact of the bug is for the system.
• Priority obviously dictates how urgently the issue should be fixed.
• Fixes are carried out based also on the project’s priorities
• The Priority status is set by the tester to the developer mentioning the time frame to fix a defect. If High priority is mentioned then the developer has to fix it at the earliest.

Severity:

• Severity is related entirely to the quality standard.
• Logically, severity enquires how severely the issue is affecting the functionality.
• The severity type is defined by the tester based on the test cases and functionality.
• Severity is assigned by tester according to the seriousness of the bug.

What makes a website fast

How long does it take to build an app

Qualified User Story

Most of Agile test teams seem to initially struggle with understanding how big (or small) a User Story is, relative to Epics, Features, and Tasks.




It doesn’t help when they first ask how big user stories are and the first response to get is “it depends“.

It’s not uncommon to find team members asking if they can call smaller stories a minor or sub-story or a larger story a major story.  

But then they get distracted by colors of index cards or some ancillary attribute.

The Distinction

Those who identify what the business wants (you may call him or her a Product Owner) take a stab at breaking down stuff to manageable chunks.  You can call those chucks an A/B-level requirement, epic, theme, feature, or spike. It doesn’t matter what you call it.  But when the team estimates that stuff, it is still sometimes (more often than not) too big to fit into a sprint or iteration or just isn’t ready to be worked.

We need to label [this] to set it apart as work that will be committed to next.  Either it will be scheduled in an upcoming sprint or it will be pulled to the next step on a Kanban story board.  To be clear, I’m not saying the team should start working on [this], merely because they think it is small enough to be completed within a predetermined cycle.  Until your team has sufficiently defined and mapped requirements, developed acceptance criteria, and removed all known blocking dependencies, it is still not a Qualified User Story.

Though I still use the term User Story as that placeholder for conversations, I believe the Qualified User Story more appropriately identifies a placeholder for conversations that meets a definition of ready and allows the team to commit to complete something within an estimated period of time.