Driving to ZBB

With the successful release of Whidbey Beta1 a few weeks ago, we’re now moving toward Beta2. The next key milestone between now and Beta2 is “ZBB.”  It is critical to close down on open issues during the drive to ZBB, because doing so significantly impacts our execution efficiency for months to come. Hitting this deliverable is one of the key things we must do right now to ensure success at Beta2.  


So, what exactly is this impactful thing we call “ZBB”.  ZBB is an acronym used internally for “Zero Bug Bounce”.  In a single sentence, it is a point in the project where we have zero bugs for the milestone.  The importance of reaching this milestone in a project is to not only reduce any backlog of bugs, but also to help ensure that we’re on track for delivering a quality release at the end of the milestone with the issues slated to be resolved, done.


A general schedule that includes ZBB would look some thing like:

1)      Feature coding

2)      Integration of bits between feature teams

3)      Bug fixing period, open issue resolution

4)      ZBB

5)      “Bounce”* (zero bugs in the queue at this point)

*“Bounce” = expectation that additional bugs will be coming in.

6)      Continue triage and fixing bugs that directly affect the milestone release. 

7)      Ship for the milestone (e.g. a Beta)


At step 3, we will hold reviews with each team and ask them to provide status on their features and bug counts.  An important aspect of the bug count status is the trajectory of their current (bug) count to zero, and the math they’re using to get there.  An aggregation of this data allows us to find problems early and manage them as necessary.  It helps to give us better planning toward and confidence on Step 7.  Additionally, asking the teams for the ‘math’ they’re using to determine their downward bug trajectory allows us insight into the validity of the projected dates.  In other words, going thru the exercise and providing data on the math allows both the product team and the release team a better understanding and confidence of why the date is what it is.  It also helps us to manage the factors that may be causing issues with the trajectory.  For example, their math may indicate that they need more balanced resources.


All this to say; we’re currently in Step 3 for Whidbey Beta2 and are working with teams to understand their ZBB dates.  From there we’ll be determining how to best reach ZBB and drive the division teams to make sure we hit ZBB on time…this will help to put us at high confidence for shipping Beta2!

Comments (18)

  1. IlkkaP says:

    Are you using Team System or something else (internal product) to do the ZBB coordination and release integration? Or any plans to do it?

    I’d love to hear how to plan the transition or how it is/will be used in the prod environment.

    Good luck for zero "bounce"!

  2. Tom Frey says:

    Is there any propsective release date for ZBB yet?

  3. Jason Sutherland says:

    The is no "ZBB release" per se. Rather, ZBB is a milestone on the road to Beta2.

  4. Tom Frey says:

    will there be any intermediate releases like the CTP drops before Beta 2?

  5. Jason Sutherland says:

    Yes, we plan to continue delivering CTPs on a regular basis (and in advance of Beta2).

  6. Mark Stega says:

    Is the "MSDN Product Feedback Center" really connected to the development team’s bug lists?

    It seems that the old "Beta Place" bug reporting was much more responsive than the feedback center.

    This is on the basis of a small sample size (5) of bugs that I have reported thus far. Some are almost three weeks old & not really acknowledged.

  7. josh ledgard says:

    Mark: Thanks for your feedback. Currently we are averaging around 6 days for a response to issues being filed on the feedback centers. To dig deeper into your specific case I would need to get the links to the issues you are referring to. This system, like whidbey itself, is still in beta so it’s possible there are some things being overlooked.

  8. Mark Stega says:

    FDBK13101 – Posted 8/3

    FDBK12829 – Posted 8/3

    FDBK13102 – Posted 8/2, response on 8/3 (‘investigating’)

    FDBK13589 – Posted 8/11, response on 8/16 (‘investigating’)

    FDBK13103 – Posted 8/2, response on 8/10 (‘working on solution’)

    FDBK12831 – Posted 8/2, response on 8/19 (‘sent to dev to be fixed’)

    So the issue is really the first 3 or maybe 4

  9. josh says:


    131101… You should have gotten an initial responce on 8/3, but since then you hit a hole. The bug was actually determined to be an issue for the Compact Framework team. Internally, they are in another database and our feedback center is currently tied to only one database. The intent is that once, the linked issue is resolved someone will respond again. The CF team is investigating the issue. Here is the latest comment "Upon further investigation, it appears that CE does not actually support GlobalAlloc, which is the method that AllocHGlobal wraps. In the CE headers, GlobalAlloc is #define’d to be LocalAlloc. There is, therefore, no benefit to providing these methods to the user.

    The docs need to be correct and other such "Target Platform" errors need to be identified.


  10. josh says:

    FDBK12829,FDBK13102 : You hit the same hole again with these two issues. You should hear back once the bugs in the non-linked database are resolved. They are not yet.

    The others are in que and being worked on.

  11. Amit Chopra says:

    Hi Mark, I am with the devices team and based on your feedback we are trying to work on how best to ensure that customers know that their bugs are being worked upon.

    Amit Chopra

    Program Mananger – Visual Studio for Devices

  12. Mark Stega says:

    Nice responses – I’m glad that I found this blog! Proof once again that the blogs are worthwhile to both Microsoft & Microsoft customers as far as I am concerned. BTW, I found this blog as a reference from the Scobelizer blog…

Skip to main content