You can monitor Bug activity for a team project by using the Bugs dashboard, which shows the following charts:
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
In this topic
You can use this dashboard to answer the following questions:
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 Access to the Databases of the Data Warehouse for Visual Studio ALM.
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. For more information, see Managing Permissions.
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:
Burndown, 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.
A visual representation of the cumulative count of all Bugs, grouped by their state, for the past four weeks.
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.
A visual representation of the cumulative count of all Bugs, grouped by their priority, for the past four weeks.
A horizontal bar chart with the total count of active Bugs that each team member has currently assigned to them, grouped by priority.
List of the active Bugs. The list is derived from a Team Web Access Web part.
List of upcoming events. The list is derived from a SharePoint Web part.
Count of active, resolved, and closed work items. You can open the list of work items by clicking each number. This list is derived from a Team Web Access Web part.
List of recent builds and their status. You can view more details about a build by clicking it. This list is derived from a Team Web Access Web part.
: Build in Progress
: Build Not Started
: Build Succeeded
: Build Failed
: Build Stopped
: Build Partially Succeeded
List of the most recent check-ins. You can view more details about a specific check-in by clicking it. This list is derived from a Team Web Access Web part.
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.
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?
For more questions to ask based on the indicators that appear in the dashboard, see the following sections:
Bug Progress Indicators
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.
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.
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.
Bug Trend Indicators
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.
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.
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.
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.
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.
Bug Priority and Distribution
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.
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.