<div dir="ltr"><div class="gmail_default" style="font-family:georgia,serif">Thanks, Max and Kevin!</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default"><font face="georgia, serif">+1 to Kevin's idea: "Along with paying down tech debt, I would personally like to see us focus more on fixing what we already have, before moving on to create new shiny (and buggy) features."</font></div><div class="gmail_default"><font face="georgia, serif"><br></font></div><div class="gmail_default"><div class="gmail_default"><font face="georgia, serif">Also, I think that the article might be using "priority" to also describe "severity."</font></div><div class="gmail_default"><font face="georgia, serif"><br></font></div><p dir="ltr" id="gmail-docs-internal-guid-2c2632f9-2fb8-e562-fe75-3e1aef992752" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="vertical-align:baseline"><font face="georgia, serif"></font></span></p><div class="gmail_default" style="font-family:georgia,serif;display:inline"><font face="georgia, serif">I think of p</font></div><font face="georgia, serif">riority <div class="gmail_default" style="display:inline">a</div>s business impact while <div class="gmail_default" style="display:inline">s</div>everity is customer impact.<div class="gmail_default" style="display:inline"> </div></font><span style="font-family:georgia,serif">While high severity bugs will likely be high priority, they aren't always.</span></div><div class="gmail_default"><font face="georgia, serif"><br></font><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="vertical-align:baseline"><font face="georgia, serif">That's because </font></span><span style="font-family:georgia,serif">s</span><font face="georgia, serif">everity is pretty easy to determine- it's absolute and won't change over time. </font><span style="font-family:georgia,serif">Priority, on the other hand, might change. <br><br></span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:georgia,serif"></span></p><div class="gmail_default" style="font-family:georgia,serif;display:inline">As a QA Manager once explained to me, if you have termites, that is probably high severity and high priority. If you then discover that there is a snake in the house, that is also likely to be high severity and even higher priority than the termites.<br></div><font face="georgia, serif"><br></font><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="vertical-align:baseline"><font face="georgia, serif">So severity is an input to priority, and priority is relative while severity is absolute. </font></span></p></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 15, 2016 at 10:50 AM, Kevin Smith <span dir="ltr"><<a href="mailto:ksmith@wikimedia.org" target="_blank">ksmith@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:verdana,sans-serif">Thanks for sharing this, Max. I like the general idea from the article, and especially that pretty table. I also very much appreciate that the author recognized that sometimes even cosmetic issues that only affect some users deserve a high priority, because they are so embarrassing. For example, if we misspelled "wikipedia" somewhere, that might be worth fixing asap. <br><br></div><div style="font-family:verdana,sans-serif">Before reading the article, I found myself triggered by the concept of prioritizing bugs at all. I believe that any small bug, even a cosmetic one, could be hiding some deeper, scarier bug. So I'm a fan of the "broken windows" theory[1] which recommends fixing all the little things as they pop up. Along with paying down tech debt, I would personally like to see us focus more on fixing what we already have, before moving on to create new shiny (and buggy) features. <br><br><br>[1] <a href="https://blog.codinghorror.com/the-broken-window-theory/" target="_blank">https://blog.codinghorror.com/<wbr>the-broken-window-theory/</a><br></div></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span><font color="#888888"><br>Kevin Smith<br>Agile Coach, Wikimedia Foundation<br></font></span><font><font><i><font color="#888888"><br></font></i></font></font></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote"><div><div class="gmail-h5">On Thu, Sep 15, 2016 at 10:23 AM, Max Binder <span dir="ltr"><<a href="mailto:mbinder@wikimedia.org" target="_blank">mbinder@wikimedia.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-h5"><div dir="ltr">Via Corey on the iOS team:<br><a href="https://hackernoon.com/bugs-priority-3b5cf5f6aadd?source=linkShare-3607e4b9ed19-1473801964" target="_blank">https://hackernoon.com/bugs-pr<wbr>iority-3b5cf5f6aadd?source=lin<wbr>kShare-3607e4b9ed19-1473801964</a><span><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>
<br></div></div>______________________________<wbr>_________________<br>
teampractices mailing list<br>
<a href="mailto:teampractices@lists.wikimedia.org" target="_blank">teampractices@lists.wikimedia.<wbr>org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" rel="noreferrer" target="_blank">https://lists.wikimedia.org/ma<wbr>ilman/listinfo/teampractices</a><br>
<br></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
teampractices mailing list<br>
<a href="mailto:teampractices@lists.wikimedia.org">teampractices@lists.wikimedia.<wbr>org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" rel="noreferrer" target="_blank">https://lists.wikimedia.org/<wbr>mailman/listinfo/teampractices</a><br>
<br></blockquote></div><br></div></div>