[teampractices] Article on prioritizing bugs

[Max Binder]

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.

[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

https://hackernoon.com/bugs-priority-3b5cf5f6aadd?source=lin
kShare-3607e4b9ed19-1473801964
[My copy-pasta from the other thread]
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
https://lists.wikimedia.org/mailman/listinfo/teampractices

[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.

Post by 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

https://hackernoon.com/bugs-priority-3b5cf5f6aadd?source=lin
kShare-3607e4b9ed19-1473801964
[My copy-pasta from the other thread]
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
https://lists.wikimedia.org/mailman/listinfo/teampractices

_______________________________________________
teampractices mailing list
https://lists.wikimedia.org/mailman/listinfo/teampractices