War Room Series Part 2: The Bug Bar

After reading part 1 of this series on War Room, you might be asking yourself some very important questions:

1. What is the Agenda for the War Room meetings?
2. What are the reasons why a bug is not approved to be fixed during War Room?
3. What is in the meeting minutes that will be sent out to a very large distribution list?
4. How do you know when the product is ready to ship?
5. What are the Rules of War Room?
6. What happens to a bug when it is rejected by the Release Manager?

All of your questions will be answered in the next few parts of this series. This post is about the Bug Bar and how it’s used in the War Room process.

What is the Bug Bar?

As you now know the purpose of War Room is to minimize code churn the closer we get to releasing a new product or feature. The Bug Bar will specify the criteria that must be met for a bug to be considered severe enough during War Room for the Release Manager to approve a check-in that will churn the code. That code churn is what we are trying to avoid, so the closer we get to release the more restrictive we want to be on approving bugs.

At the beginning of War Room the bug bar is set in the first war room meeting, it usually starts at a 3 based on the schedule and stability of the product. The closer we get to release the lower the bug bar gets. The bug bar should be at 1 when the code is released, this will ensure the code is only changed for the most critical bugs.

Definition of each Bug Bar level

Bug Bar 1 (High or Highest)

• Core product feature or major scenario is not functioning
• Major security issue or vulnerability
• Misspelling, placeholder text, bad characters, improper grammar, broken graphics, incomplete translation or anything else that makes the product look unsightly or unprofessional
• Improper installation or upgrade of the product
• Product instability, such as:
  • Product crashes
  • Severe performance degradation
  • Data corruption
  • Excessive CPU/memory/AWS Resource consumption
• Missing or severely deficient Help (if required)
• Issues that would cause significant support impact or call volume
• Major/core product feature is not implemented per spec
• Any other “Recall Class” bug.

Bug Bar 2 (Medium)

• Non-core product feature is not implemented per spec
• Working feature but bad user experience
• Non-core product features or non-major scenarios are not functioning without a workaround. Feature/scenario requires a knowledge base article or training
• Code Changes required to remove or prevent Tech Debt found during a code review.

Bug Bar 3 (Low)

• Some loss of functionality or “quirky” behavior in core or non-core feature
• There is an acceptable and easily discoverable workaround
• Unclear or misleading language.

Bug Bar 4 (Product Enhancement)

• Improvement to existing feature

Now that the Bug Bar has been defined for the War Room team the bugs can be set appropriately and if they meet the Bug Bar they will be reviewed by the Release Manager. The Release Manager will approve or reject the bugs during the daily meeting, if rejected the PM will prioritize the bug to be fixed after the release.

In the final part of this series, you will learn about the Rules of War Room, what is in the meeting minutes and how you will know when the product is ready to ship. At that point you should be able to run your own War Room and ship amazing products and features like we do here at Knowbe4.