3 ms·
Our PM would identify and prioritize customer requirements (so creating a foobar in the UI is P1, renaming it is P2, showing a loading spinner is P3, etc). Then
by marshmellman 7y ago
Our PM would identify and prioritize customer requirements (so creating a foobar in the UI is P1, renaming it is P2, showing a loading spinner is P3, etc). Then our QA tester would “bug bash” and assign priority to bugs according to the requirement it violated. We had a policy of “GA releases cannot contain any >P2 priority bugs” or similar.
This system worked well with a technical PM, proper release planning (allocating time to test and fix bugs), and the autonomy to bend the rules a bit in either direction (e.g. “this bug is technically P4 but it’s embarrassing and will be easier to fix now”). At times we had an additional ongoing policy of pulling several non-blocker bugs into each sprint to ensure they weren’t neglected.