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