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 <mbin...@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@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/teampractices > >
_______________________________________________ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices