War Room Series Part 3: The Rules

This is the end of the short blog series about War Room. The first post explained what War Room is, followed by the second post which explained the bug bar. This final post will speak to the rest of what is needed to complete your War Room phase.

The very first War Room meeting is one of the most important as you might remember from part 1 of this series. This includes the list of participants that will be attending your War Room meetings. Let's start with the below list of items that need to be discussed in the first meeting:

War Room Agenda

• Review of 'Ship Criteria' (Ship Criteria is the "definition of done" for the release)
• If Ship Criteria has not been decided, then War Room decides it. Ship Criteria must be approved by the Release Manager.
• Review of product with regards to Ship Criteria
• Selection of Bug Bar Setting
• Motions for bug fixes
• Release Manager can poll War Room members for data about proposed bug fixes
• Release Manager rules on Motions, and denies any that do not meet the Bug Bar
• Target release date or date range is (re-)estimated
• If any dates are changed, notify all stakeholders immediately

After that first meeting is over all the information that is needed to start sending out your War Room Minutes will be available. This is sent out daily with updated information:

Contents of the War Room Minutes

• Product Name and Version
• Target Engineering Complete Date
  • Note if it changed from previous War Room meeting
• Release Manager
• Ship Criteria
• New Features in this release
• Current Bug Bar
• A graph of daily ship-stopper bug count and status since War Room started
• Regression Test Status (e.g. Test Matrix, Test Counts)
• Major Bug Fixes
• Optional: List of ship-stopper bugs still being worked (do not list bugs that were rejected by War Room)

As War Room continues Stakeholders will see in the daily meeting minutes that the graph of ship-stoppers will work down towards 0. It is great when you get to 0 bugs! However, you should expect the graph to "bounce" at least once, so it is risky to ship the first time the graph hits 0. This event is called Zero Bug Bounce (ZBB), and you will have at least one ZBB in your War Room. We always do.

Finally a few rules to remember, these were talked about in the three blog posts but it can't hurt to have a little reminder since they are very important.

Rules for the Team while they are in War Room

• NO CODE CHANGES ARE CHECKED IN WITHOUT RELEASE MANAGER APPROVAL
• War Room starts when the last Sprint ends OR when the product is Feature Complete
• War Room meets every day, and is time-boxed to 15 minutes
• War Room continues until the product is released
• Check-ins are approved only if the bug meets the "Bug Bar"
• Minutes are taken and sent to the Team and all Stakeholders immediately after War Room adjourns.

This blog post concludes the War Room Series. You now have all the information and rules needed to complete your own War Room phase. If you remember that the goal of War Room is to push the product through final testing steps, communicate daily status to all Product Stakeholders and get the product RELEASED, then you will succeed in delivering a great product. I hope you enjoyed the series!