Don’t Confuse a Bug’s Priority with Its Severity
Misunderstanding of priority and severity fields has been going on for decades and suggests that they&#x27;re not really useful terms.<p>Priority in particular is quite subjective and also changes depending on what else is going on (other tickets perhaps?)<p>Having said that, the bug tracker we use provides the fields by default and we try to use them intuitively. We also try to discourage the &quot;everything is P0&quot; behaviour that happens when people use an arbitrary numerical scale. (What even is P0? I see it pop up when people discover that all their current tickets are P1.<p>Anyway, here&#x27;s ours. They&#x27;re kind of ordered but mostly try to be descriptive and sympathetic to the idea that the judgement is subjective:<p>Priorities<p>* &quot;If time permits&quot;<p>* &quot;Next&quot;<p>* &quot;Do not defer&quot;<p>* &quot;Blocks dependants&quot;<p>* &quot;Release blocker&quot;<p>* &quot;Don&#x27;t go home&quot;<p>The default is &quot;If time permits&quot;.<p>Note how all of them are pretty &quot;important&quot; sounding except the &quot;lowest&quot; which instead admits that sometimes things just can&#x27;t be done because of other factors rather than because they&#x27;re not important.<p>&quot;Next&quot; means &quot;do this next&quot; or &quot;in the next phase of work &#x2F; sprint &#x2F; release&quot; and things can climb up to this priority as we take decisions.<p>&quot;Do not defer&quot; means that it <i>must</i> be done in the milestone it&#x27;s allocated to. It can&#x27;t be deferred to another milestone. i.e. we&#x27;ve made decisions that mean it can&#x27;t be deferred to the next phase. This is for things that we&#x27;ll need for the next phase or will become blockers but aren&#x27;t yet. It&#x27;s not for things where we have generally decided that Now Is The Time. There must be a specific reason it can&#x27;t be deferred. We use the milestone features to actually decide what&#x27;s in or out of a scope of work.<p>&quot;Blocks dependants&quot; is pretty high up and as such needs to be explicit about what it&#x27;s used for. If your bug blocks something else or has something that depends on a fix then the schedule is going to get messy if it&#x27;s not done. It&#x27;s hard for someone with authority to wedge something in here because they feel like it.<p>&quot;Release blocker&quot; is also pretty high up. This is where people get to jump up and down and explain why they think their bug is so important (and why it&#x27;s doesn&#x27;t fit into &quot;do not defer&quot;). This is for stuff that means we can&#x27;t actually ship the release rather than things we&#x27;d just like to be in it. For example &quot;we can&#x27;t build the software until this is fixed&quot;. Hopefully reasonably rare stuff. You need to explain why this blocks a specific release rather than the release otherwise being enough better than the previous one to deliver value to users.<p>&quot;Don&#x27;t go home&quot;. Sometimes things really are that bad and need to be fixed. At least the person assigning this knows what they&#x27;re asking, what the implications are and how bad it looks if everything always ends up in this bucket.<p>Severity works a bit differently. These things are hints from the reporter about the impact of this bug. They really are very subjective.<p>* Don&#x27;t care<p>* Embarrassing<p>* Minor peril<p>* Major shitstorm<p>* QA blockers<p>* Showstopper<p>&quot;Don&#x27;t care&quot; is the default. We want to capture everything we know about our software and encourage people to not feel too &quot;whiny&quot; about filing the notes. This is often for things that end up as &quot;enhancements&quot; or &quot;tasks&quot; rather than &quot;defects&quot;.<p>&quot;Embarrassing&quot;. This is something that a user would notice and be left with an impression that we have less attention to detail than the best in the industry.<p>&quot;Minor peril&quot;. This is a bug that&#x27;s going to cause friction or trouble and give the user an uneasy sense or stop them from building confidence in the software.<p>&quot;Major shitstorm&quot;. I&#x27;m never profane in my software but someone suggested this and lots of people liked it and had a good idea of how it should be used. This is for stuff that causes problems when the feature is used. Stuff that leaves a persistent mess that needs to be cleaned up by hand or corrupts some state or something.<p>&quot;QA blockers&quot;. Without fixing these bugs then we&#x27;re unable to test our software properly. This means we might attract regressions and we probably shouldn&#x27;t be releasing stuff to users. For example, if you can&#x27;t save a record that contains the new features then you can&#x27;t test the corresponding load functionality.<p>&quot;Showstoppers&quot;. These are bugs that cause the whole software to break. Crash bugs, things that destroy user data, etc.<p>Most of our open bugs mostly sit at &quot;don&#x27;t care&quot;, &quot;embarrassing&quot;, &quot;if time permits&quot;, &quot;next&quot; and occasionally &quot;do not defer&quot;. If stuff starts creeping up the ladder then we know we have a problem coming. If stuff starts to appear straight at the top of the ladder then we get those things fixed ASAPs: they don&#x27;t hang around as &quot;open&quot; for very long!<p>A lot of the &quot;higher&quot; values are things that help us deal with interactions. Problems on their own are often tractable. When things start affecting other things and causing knock-on effects then trouble occurs. We try to head that off by knowing about it when it comes in and fixing those things quickly.