[teampractices] Article on prioritizing bugs

[Grace Gellerman]

Thanks, Max and Kevin!

+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."

Also, I think that the article might be using "priority" to also describe
"severity."

​I think of p
riority
​a​
s business impact while
​s​
everity is customer impact.
​
While high severity bugs will likely be high priority, they aren't always.

That's because s​everity is pretty easy to determine- it's absolute and
won't change over time.  Priority, on the other hand, might change.

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.

So severity is an input to priority, and priority is relative while
severity is absolute.

On Thu, Sep 15, 2016 at 10:50 AM, Kevin Smith <ksmith at wikimedia.org> wrote:

> 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.
>
> 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.
>
>
> [1] https://blog.codinghorror.com/the-broken-window-theory/
>
>
> Kevin Smith
> Agile Coach, Wikimedia Foundation
>
>
> On Thu, Sep 15, 2016 at 10:23 AM, Max Binder <mbinder at wikimedia.org>
> wrote:
>
>> Via Corey on the iOS team:
>> https://hackernoon.com/bugs-priority-3b5cf5f6aadd?source=lin
>> kShare-3607e4b9ed19-1473801964
>>
>>
>> [My copy-pasta from the other thread]
>> Some things that jumped out at me:
>>
>> However, often times the criteria for making tradeoffs aren’t made
>>> explicit, and can be detrimental if not understood by all people involved.
>>
>>
>> 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.
>>
>>
>>
>>>    - *What kind of defect? *— The spectrum of defects is very large,
>>>    where does this fall in that spectrum as best as I can see?
>>>    - *What is the frequency of the defect?* — Does this happen every
>>>    time, some times, some times for some users, very infrequently, only when
>>>    the moon is full?
>>>
>>> These two variables (and maybe more for your organization) are key in
>>> decoupling the gut decision from the right decision.
>>
>>
>> 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.
>>>
>>
>> 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.
>>
>> If you use a spectrum of *value*, 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.
>>
>> _______________________________________________
>> teampractices mailing list
>> teampractices at lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/teampractices
>>
>>
>
> _______________________________________________
> teampractices mailing list
> teampractices at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20160915/09dcc256/attachment-0001.html>