A work item is a database record which Visual Studio Team Foundation uses to track the assignment and state of work. The MSF for Agile Software Development process defines five work items to assign and track work. These five work items are the scenario, quality of service requirement, task, bug, and risk.
Work products are files, documents, specifications, binaries, parts, and other tangible items that are necessary to complete activities and build the product. Many times the creation of one work product is dependent on the completion of another work product.
Team Build
Project health charts aggregate metrics from work items, source control, test results, and builds. They answer questions about the actual state of your project at many scales: for the days within an iteration, iterations within a project, or projects with in a program. The questions are also relevant for many kinds of work items such as scenarios, quality of service requirements, tasks, and bugs.
Quality Indicators
What is the quality of the software? Ideally, test rates, bugs, and code churn would all produce the same picture, but often they do not. When you find a discrepancy, you need to examine in further detail the appropriate build and data series. This graph combines the test results, code coverage from testing, code churn, and bugs, to help you see many perspectives at once.
Bugs by Priority
Are the correct bugs being found and triaged? Bugs reported by priority assess the effectiveness of two things: bug hunting and triage. Discovering bugs is a normal part of product development. Often however, the easy-to-find bugs aren’t the ones that will annoy customers the most. If the high-priority bugs are not being found and a disproportionate number of low-priority bugs are, redirect the testing efforts to look for the bugs that matter. In triage, it is easy to over-prioritize bugs beyond the capacity to resolve them, or under-prioritize them to the point where customers are highly dissatisfied.
