5 ms·

>A more refined approach is to triage the bugs into 4 or 5 levels of severity and then you might reasonably agree that at least all sev1 bugs must be fixed befo

>A more refined approach is to triage the bugs into 4 or 5 levels of severity and then you might reasonably agree that at least all sev1 bugs must be fixed before new functionality is added. Of course, in practice this just means 3 or 4 levels of bugs that will never get fixed and languish in a backlog until the team / project gets re-orged and the entire backlog is wiped clean. Okay, I'm joking. Sometimes those bugs become old enough they refer to features that no longer exist or can't be reproduced and then get marked as "won't fix"

bradwood 4y ago
So be it, if that's the case. At least it showed that a proper trade-off between features and bugs was made at the time. Remember that the triage can and should be rerun from time to time. Already open bugs could then be down- or upgraded in their severity as context evolves.
tagspace 4y ago
"in practice this just means 3 or 4 levels of bugs that will never get fixed" - this is so spot on! This is exactly what we were thinking: realistically, if we don't fix it now, it will never actually get fixed. So, if it's important enough to fix, why not fix it now.
sanitycheck 4y ago
> Of course, in practice this just means 3 or 4 levels of bugs that will never get fixed and languish in a backlog until the team / project gets re-orged and the entire backlog is wiped clean. I've never had much success getting a "won't fix" decision out of a PM or designer, and my time is too limited and valuable to spend debating it. If developers all know "low priority" means "never do" and "stakeholders" believe that their pet quibble will be fixed one day (even though they will never allocate time to do that) then work can continue in a sensible fashion.