[teampractices] Article on prioritizing bugs

Thu Sep 15 17:23:30 UTC 2016

Via Corey on the iOS team:
https://hackernoon.com/bugs-priority-3b5cf5f6aadd?source=
linkShare-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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20160915/8c7f1368/attachment.html>