<div dir="ltr">Via Corey on the iOS team:<br><a target="_blank" href="https://hackernoon.com/bugs-priority-3b5cf5f6aadd?source=linkShare-3607e4b9ed19-1473801964">https://hackernoon.com/bugs-<wbr>priority-3b5cf5f6aadd?source=<wbr>linkShare-3607e4b9ed19-<wbr>1473801964</a><span class="gmail-HOEnZb"><font color="#888888"><br></font></span><br><div><br>[My copy-pasta from the other thread]<br>Some things that jumped out at me:<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">However, often times the criteria for making tradeoffs aren’t made 
explicit, and can be detrimental if not understood by all people 
involved.</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hopefully the person assigning priority has been clear and open about 
how they are making the decisions, but I’d guess more often than not, 
it’s a mix of gut feeling and maybe, current mood.</blockquote><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><ul><li name="e428"><b>What kind of defect? </b>— The spectrum of defects is very large, where does this fall in that spectrum as best as I can see?</li><li name="28dd"><b>What is the frequency of the defect?</b> — Does this happen every time, some times, some times for some users, very infrequently, only when the moon is full?</li></ul>These two variables (and maybe more for your organization) are key in decoupling the gut decision from the right decision.</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Could this be the right way to keep your collection of bugs, features, 
and the like organized? Maybe, maybe not, it’s really whatever works for
 your organization. <br></blockquote><div><br></div>I agree that 
priority is about tradeoffs. I like to treat bugs the same way as debt 
and features, in that they should explicitly say why a team should 
engage. I think a spectrum for assigning priority, like the one 
described in the article, can be useful. I think it's more important 
(and not mutually exclusive) to ensure the task clearly states it's 
value. <br><br>If you use a spectrum of <i>value</i>, you can apply a 
similar methodology for coordinating priority to all work with which the
 team engages. I think this is also more flexible, since your rubric for
 priorities may shift over time (or suddenly), but clearly describing 
the value of a task makes it easier to shift gears on 
already-prioritized tasks.</div></div>