Inside VSTS

Team Foundation Server Reports

The biggest benefit in TFS is its 25 out-of-the-box reports, but three of them are especially crucial to organizations. Jeff goes over each one.

• By Jeff Levinson
• 05/19/2008

In this article, I'm going to cover a couple of choice reports that I think give an organization -- and a development team -- the biggest bang for the buck. There are 25 out-of-the-box reports in the CMMI template (these reports differ slightly for the Agile template), three of which are necessary for a team to improve any of their processes.

Unplanned Work Report
The first report -- and the one that always helps make a good case when you're talking to your customer -- is the Unplanned Work report, also known as the Scope Creep report. Figure 1 shows a fairly typical example. You can clearly see that as the team has been closing planned work items (yellow), more work items have been added to its schedule. So while the team is working at a good clip, it's actually losing ground.

It's incredibly difficult to explain this to a customer. After all, you not only have to keep track of all the new requests being made and all of the work being done; you have to then somehow let the customer know about all of it. But once you show them a picture -- well, it's worth a thousand words!

Use this report to make customers understand why a schedule may be slipping. Or, better yet, prevent a schedule from slipping by bringing this up to the customer at the earliest possible moment.

Remaining Work Report
The second and most important report -- as well as the most beneficial -- is the Remaining Work report. This report is invaluable in that it allows teams to start making predictions based on trends. It can also be used to proactively make decisions instead of just reacting to problems.

Figure 2 shows an example of a project in trouble. Figure 3 shows a project that's right on time. Take a look at these figures side by side. Given a known start date, a known end date and a known amount of work, you can easily calculate the required velocity (that is, the number of work items needing to be closed per day/week/month, etc.) to complete the project.

With this information in hand you can see that in Figure 2, there's enough information after the first or second week that would make you say, "Hold on, we have a problem here" and then take steps to alleviate the issues affecting the team. Likewise, looking at Figure 3, you can say, "Things are going well, the project is under control at an early stage."

Quality Indicators Report
The third report is only valuable if your team does unit testing and nightly builds. If you haven't seen me rant about the importance of nightly builds, I'll give it to you in shortened form here: Do it. It's easy to set up, is no different than a weekly build (which you should also have) and you'll thank me for it later.

Figure 4 shows the Quality Indicators report. This report shows a number of metrics that are critical for evaluating the quality of your code. The bars on the graph represent the status of tests. The more tests, the better; the more tests go green (pass), the better. The dark purple line represents code coverage (how much of the code your tests are exercising) and the light purple line represents the code churn (how much the code changed from one build to another).

Looking at this report, you can see that this project is clearly in trouble. There are numerous reasons for this represented in the graph: The number of passing tests is decreasing. The number of failing tests has remained steady, meaning no one is fixing the code. As the project is progressing, less and less of the code is being exercised, meaning that while code is being added, tests aren't being added.

Finally, the code churn is going up. As you near the end of a project, the code churn should actually decrease. There are some occasions in which it would spike on a day-to-day basis, but not as a sustained trend once it starts declining. This indicates that some major chunks of code were added or changed.

Assuming this is toward the end of the release cycle, I wouldn't want to release this code; there's just too much uncertainty and the only thing that is certain is that the code hasn't been adequately tested. That's a lot of information to get from a single report!

These are just three of the 25 reports available to you. Some reports are more significant than others, depending on what information is important to you, but they require that you take a consistent approach to gathering metrics. Fortunately, Team System helps with that problem as well, since it makes gathering the data and producing the reports painless and virtually transparent to the development team. Use these reports to actively manage your projects and head-off any potential disasters.