Bugs Dashboard (CMMI)

You can monitor bug activity for a team project by using the Bugs dashboard, which shows the following charts:

• bug burndown

• the rate at which the team is finding, resolving, and closing bugs over time

• the count of priority bugs over time

• the current count of active bugs that are assigned to each team member

  Note

  You access dashboards through your team project portal. You can access the Bugs dashboard only if that portal has been enabled and is provisioned to use SharePoint Server Enterprise Edition. For more information, see Dashboards (CMMI).

In this topic Data displayed in the dashboard Required activities for tracking bugs Monitoring active bugs and bug trends

You can use this dashboard to answer the following questions: How quickly is the team resolving and closing bugs? Is the team fixing bugs quickly enough to finish on time? How many bugs is the team reporting, resolving, and closing per day? Is the team resolving priority 1 bugs before priority 2 and 3 bugs? Does any team member have a backlog of priority 1 bugs that warrant redistribution? What is the status of last night's build? What were the most recent check-ins?

Required permissions

To view the dashboard, you must be assigned or belong to a group that has been assigned the Read permissions in SharePoint Products for the team project. To modify, copy, or customize the dashboard, you must be assigned or belong to a group that has been assigned the Members permissions in SharePoint Products for the team project. For more information, see Add users to team projects.

To modify a report in Office Excel, you must be a member of the TfsWarehouseDataReaders security role in SQL Server Analysis Services. You must also be assigned or belong to a group that has been assigned the Members permissions in SharePoint Products for the team project. For more information, see Grant permissions to view or create reports in TFS.

To view a bug or other type of work item, you must be a member of the Readers group or your View work items in this node permission must be set to Allow. To create or modify a bug or other type of work item, you must be a member of the Contributors group or your Edit work items in this node permission must be set to Allow.

Data displayed in the dashboard

The team can use the Bugs dashboard to understand how well the team is finding, resolving, and closing bugs. Specifically, the dashboard displays the Web parts that the following illustration shows and the following table describes:

Note

Progress, trend, and bar charts, reports through , do not appear when the server that hosts Analysis Services for the team project is not available.

For more information about how to interpret, update, or customize the charts that appear in the Bugs dashboard, see the topics that are listed in the following table.

Web part	Data displayed	Related topic
	A visual representation of the cumulative count of all bugs, grouped by their state, for the past four weeks.	Bug Progress Excel Report
	Line chart that shows the rolling average of the number of bugs that the team has opened, resolved, and closed for the past four weeks. The rolling average is based on the seven days before the date for which it is calculated.	Bug Trends Excel Report
	A visual representation of the cumulative count of all bugs, grouped by their priority, for the past four weeks.	Bugs by Priority Excel Report
	A horizontal bar chart with the total count of active bugs that each team member has currently assigned to them, grouped by priority.	Bugs by Assignment Excel Report
	List of the active bugs. The list is derived from a Team Web Access Web part.	Not applicable
	List of upcoming events. The list is derived from a SharePoint Web part.	Not applicable
	Count of active, resolved, and closed work items. You can open the list of work items by selecting each number. This list is derived from a Team Web Access Web part.	CMMI process template work item types and workflow
	List of recent builds and their status. You can view more details about a build by selecting it. This list is derived from a Team Web Access Web part. Legend: : Build not started : Build in progress : Build succeeded : Build failed : Build stopped : Build partially succeeded	Managing and Reporting on Builds
	List of the most recent check-ins. You can view more details about a specific check-in by selecting it. This list is derived from a Team Web Access Web part.	Develop code and manage pending changes

Required activities for tracking bugs

For the reports that appear in the Bugs dashboard to be useful and accurate, the team must perform the following activities:

• Define bugs, and specify their Iteration and Area paths.

• Assign each bug to the team member who is working to resolve or close it.

• Specify the Priority of each bug.

• Update the State of each bug as the team fixes, verifies, and closes it.

Monitoring active bugs and bug trends

Team members can use the Bugs dashboard to determine whether they are managing the list of active bugs according to established team goals and agile practices. By unit testing each increment of code before check-in, the team can reduce the overall number of bugs that the team must find. A team that focuses on being able to ship each increment of code removes defects incrementally and minimizes ongoing bugs.

By using the Bugs dashboard, the team can answer the following questions:

• Is the number of active bugs acceptable based on team goals? Is the team postponing too many bugs?

• Is the team finding, fixing, and closing bugs quickly enough to meet expectations and at a rate that matches previous development cycles?

• Is the team addressing high priority bugs before lower priority bugs?

• Does any team member need help in resolving bugs?

Bug progress indicators

Indicator	Questions to ask
The band for active bugs is becoming wider. If the width of the team's band for active bugs is increasing, the bug backlog is growing. The team is finding more bugs than it can resolve or close. A widening band of active bugs might indicate that a bottleneck is slowing the team's ability to resolve and close bugs.	Are team members being reallocated to other, non-priority tasks? Are other issues blocking the team's ability to resolve and fix bugs?
The number of active bugs is not changing. A flat trend in the number of active bugs indicates that the team is not finding bugs.	Is the test coverage sufficient? Are other issues blocking the team's ability to find bugs?
The number of resolved or closed bugs is not changing. When the number of bugs that the team is resolving or closing remains flat for long periods of time, team members might not be able to resolve or close bugs.	Are team priorities correctly set? Are team members over allocated on other tasks? Are team members correctly tracking their bug status?

Bug trend indicators

Indicator	Questions to ask
The team is resolving many bugs in each time period. A high resolution rate usually indicates that the team is making good progress.	Is the team promptly closing the bugs that it resolves? The rate of closure should resemble the rate of resolution. Is the team reactivating bugs at an acceptable rate?
The team is resolving bugs quickly but not closing them. Team members who are assigned to verify fixes might be spread too thin, or different priorities might keep those team members from closing resolved Bugs.	Are test resources over-allocated? Should the team revisit test priorities? For more information about these metrics, see Test dashboard (CMMI).
The team is finding few bugs in each time period. The team might struggle to find bugs in a high-quality solution or with ineffective testing.	Do the metrics for code coverage, code churn, or test progress indicate a problem with the code or testing? For more information about these metrics, see Quality Dashboard (CMMI)
The team is finding about the same number of bugs in successive time periods. If the team finds the same number of bugs week after week or iteration after iteration, you might investigate the underlying cause. Early in the testing cycle, the tests might not be rigorous or advanced enough to find many bugs. In early iterations, this situation is expected. However, as the product matures, tests should exercise broader scenarios and integrations.	Are the tests adequate to test the requirements that the team is developing? Have the tests become stale or are they testing the wrong functionality? Is the test team rigorously testing each requirement? For more information about these metrics, see Test dashboard (CMMI).
The team is finding many bugs in each time period. The team might find bugs easily in sloppy code, in newly integrated code, with effective testing, or during a specific event, such as a bug bash.	Do the metrics for code coverage, code churn, or test progress indicate a problem with the code or testing? For more information about these metrics, see Quality Dashboard (CMMI).

Bug priority and distribution

Indicator	Questions to ask
The number of active higher priority bugs is larger than the number of active lower priority bugs. When the number of high priority bugs is much larger than the number of lower priority bugs, the team might be focusing on lower priority items first.	Is the team fixing bugs in the order of priority set by the team? Are issues blocking the team's ability to fix the higher priority bugs?
Bug assignments are not evenly distributed. The team might consider reassigning work when many bugs are assigned to one or two team members and only a few to other team members.	Should the team balance the workload by reassigning bugs?