The courses we are running specifically mention that “all our work is prioritised“. Project teams have extended the practice of using MoSCoW prioritisation beyond user stories and are using it on defects.
But whereas the rules around prioritising user stories are clear, how does one prioritise a bug? It seems that teams are classifying bugs as “Must Fix”, “Should Fix” and “Could Fix” depending on the impact.
I see a couple of problems with this logic:
As applied to User Stories, MoSCoW priorities apply within a given timeframe. A story can be, for example, a Must Have for the project, a Should Have for the Increment, and only a Could Have at the timebox level. Applying this same structure to bugs implies that they can be re-prioritised in future timeboxes. They can’t.
The process of deciding on the priority of a bug takes time, it is largely subjective and implies that some will never be fixed (something the business may not be happy with).
Consider this : when a bug is identified, instead of prioritising it (and going through all the negotiation that implies), why not simply ask the appropriate Business Ambassador or Advisor whether he/she would accept the applicable user story with that bug unresolved. If the answer is No, (bearing in mind that fixing it means time is not spent on other user stories instead), raise the bug and get it fixed ASAP! If the answer is Yes, don’t raise the bug at all – what’s the point?
Teams using story points to estimate their user stories and velocity to plan their work will know that bug-fixing does not count towards velocity. Essentially, a defect is what is preventing a user story achieving “Done” status. The effort of defect management is, in itself, a waste of valuable time and should be kept to a bare minimum.