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
about how to use various aspects of Team System (testing, change management,
branching, etc.) but I discovered that I've left out the most important aspect
out: visibility! Team Foundation Server without visibility is just a glorified
Visual SourceSafe with some basic work management capabilities. The real benefits
of Team System to an organization are the reports.
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
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.
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.
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
Jeff Levinson is the Application Lifecycle Management practice lead for Northwest Cadence specializing in process and methodology. He is the co-author of "Pro Visual Studio Team System with Database Professionals" (Apress 2007), the author of "Building Client/Server Applications with VB.NET" (Apress 2003) and has written numerous articles. He is an MCAD, MCSD, MCDBA, MCT and is a Team System MVP. He has a Masters in Software Engineering from Carnegie Mellon University and is a former Solutions Design and Integration Architect for The Boeing Company. You can reach him at Jeff.Levinson@nwcadence.com.