Share via

Weekly P1 ZBB

  • Article

We've started a new-to-us practice around here: The weekly P1 ZBB.

Each bug in our bug database gets assigned a priority:

0 - drop everything and fix this, because people are completely blocked because of this.

1 - really important bug that we really need to fix, and preferably soon.  crashes/hangs/major functionality broken

2 - important issue in the product.  We will fix nearly all of these before we ship

3 - polish issue.  We will fix many of these, but certainly not all.

4 - suggestion.  We'll fix as time allows.

As we work through the bugs on our way to RTM, we want to make sure we stay focused on fixing the right bugs.  Bugs should usually be fixed in priority order.

  • P1 bugs usually obscure other less important issues
  • When a product has plenty of P1 bugs, you're not likely to bother reporting more minor issues
  • Fixing P1 bugs usually has the biggest impact on the value of the product to customer
  • P1 bugs interfere productivity - testers can't test, internal users can work, developers on the team have to work around issues.

To help keep the team focused on doing this, we driving to fix all priority 1 (P1) bugs by the end of each week.  To stop it from being too randomizing, we only include bugs opened before Wednesday.

Comments

  • Anonymous
    May 19, 2005
    Is this practice new to you for the current development cycle or in general new to microsoft? Do different groups manage their defects/bugs in different ways. We employ something similar...

    Matt
  • Anonymous
    May 20, 2005
    The comment has been removed