Product Metrics/Release Criteria

As we drive towards Whidbey Beta 2, the Product Metrics/Release Criteria are a main guiding principle in assuring we are shipping the right quality product. These metrics/criteria are made up of a number of goals and test coverage requirements (approx. 40) which were defined during Beta 1. Some examples are:

·         Stress goals that ensure the short-term and long-term stability and reliability

·         Performance goals

·         Runtime, Design time and Serialization compatibility. Backward compatibility with previous release, type forward and backward, etc.

·         Security, shipping secure code!

·         Side-by-side, support the running side by side with previous versions

·         Localization and globalization, support a successful release in international markets

·         Community and partner feedback, make sure we are giving our customer what they want

·         Accessibility, support standards for accessibility tools, compatibility hardware accessibility features, etc

·         Application building, use the tools we ship!

·         etc

At the beginning of Beta 2 I held reviews with all the release criteria owners in order to fully understand the direction and need for each of the requirements. While reviewing each of them I spent time putting the different metrics into buckets in order to have a better understanding of what the requirements were for us to ship a high quality beta, which ones required “checkpoints” during Beta 2 in order to confirm we were on track, and what was required as part of our test pass. 

As we approach ZBB I will be holding follow-up reviews to gauge the current status of each of our release criteria, necessary updates, checkpoints, and confirm we are still tracking towards a successful high quality Beta 2. This is also an opportunity for the criteria owners to bring up any issues, risks, and/or asks as we head towards the endgame of Beta 2.