Scribd
Upload
220 views

Jira Bug Priorities: Standard Priority Rules

This document defines standard bug priorities from P0 to P3. P0 issues cause complete outages and require immediate resolution. P1 issues significantly impact users and should be addressed quickly with continuous updates. P2 issues are important but have workarounds; they are the default priority. P3 issues are nice-to-haves that can be addressed when time allows. The priorities provide expectations for urgency and which issues should block releases.

Uploaded by

Vaishali Martires
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
220 views

Jira Bug Priorities: Standard Priority Rules

This document defines standard bug priorities from P0 to P3. P0 issues cause complete outages and require immediate resolution. P1 issues significantly impact users and should be addressed quickly with continuous updates. P2 issues are important but have workarounds; they are the default priority. P3 issues are nice-to-haves that can be addressed when time allows. The priorities provide expectations for urgency and which issues should block releases.

Uploaded by

Vaishali Martires
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 3

Jira Bug Priorities

Standard priority rules


Each bug is assigned the first appropriate priority listed below from top to bottom.

P0: Outage
An outage means that some piece of infrastructure that the community relies on is down. A P0
issue is more urgent than simply blocking the next release. Such an issue causes a full outage or
makes a critical function of the product to be unavailable for everyone, without any known
workaround.

Expectation: Drop everything else and work continuously to resolve.

Example P0 issues:

 the build is broken, halting all development.


 Any reproducible crash or hang.

 Any regression from a previous publicly released version.

 Serious security issue.

 a vulnerability requires a point release ASAP.

P1: Critical
An issue that needs to be addressed quickly. Such an issue significantly impacts a large
percentage of users; if there is a workaround it is partial or overly painful. The impact of the
issue is to a core organizational function, or fundamentally impedes another team.

Expectation: Continuous status updates. P1 bugs should not be unassigned. Most P1 bugs should
block release.

Example P1 issues:

 App that does not function in some non-trivial way.


 Serious performance complaints.

 Unreproducible crash or hang that has been reported many times.

 important component is nonfunctional for important use cases.


 Site that has really very bad cosmetic problems (e.g., content overlapping such that it’s
very hard to read).

P2: Default
An issue that needs to be addressed on a reasonable timescale. Such an issue could be any of the
following:

1) An issue that would be P0 or P1 but has a reasonable workaround


2) An issue that is important to a large percentage of users and is connected to core
organizational functions,
3) An issue that is an impediment to the work of other teams and has no reasonable workaround.

P2 is especially relevant for first-use or install-time issues and is the default priority level. It does
or does not hold release always.

Expectation: Most tickets fall into this priority. These can be planned and executed by anyone
who is interested. No special urgency is associated, but if no action is taken on a P2 ticket for a
long time, it indicates it is actually just P3/nice-to-have.

Example P2 issues

 typical feature request


 bug that affects some use cases but don’t make a component nonfunctional.

 App that works but has some cosmetic problems.

 Unreproducible crash or hang.

 Language issues which affect usability

 Minor performance complaints, such as trivial memory leaks.

 Architecture issues that could help with correctness or performance but are not a clear
win in advance.

P3: Nice-to-have, not relevant to core organizational


functions.
An issue that should be addressed when able. Such an issue is relevant to core organizational
functions or the work of other teams but does not impede progress or else has a reasonable
workaround.

Expectation: Nice-to-have improvements.


Example P3 issues

 feature request that is nice-to-have- attractiveness or pleasantness of the system.


 ticket filed as P2 that no one finds time to work on.

 All enhancement requests and feature requests not covered the criteria for p1, p2, or p3.

 spelling errors in comments or code

Expectation: Nice-to-have improvements that are also very small and easy. Usually, it is quicker
to just fix them than to file a bug, but the Jira can be referenced by a pull request and shows up in
release notes.

Common adjustments to priority


 If there is a workaround, the priority may be moved down.
 If a bug gets a lot of duplicates, the priority may be moved up.

 If a bug is getting a lot of public attention, the priority may be moved up.

 If a bug is on a very important site, the priority may be moved up.

You might also like