[teampractices] Article on prioritizing bugs

[Kevin Smith]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20160915/05c22b4a/attachment.html>