Creating Agile Project Reports with TFS and Crystal Reports - Part 1
 
Published: 12 Feb 2007
Abstract
In this article Eric introduces the reader to creating management reports using Crystal Reports and Team Foundation Server (TFS) for an agile project.
by Eric Landes
Feedback
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 23951/ 31

Introduction

As more development teams move to utilizing Agile methodologies, the management tools are different than the traditional Project Management tools.  This article assumes that the reader already buys into agile principles.  For this article we will explore creating the kind of management reports that can be utilized in an agile development project.  If you are looking for an article to persuade you of agile development's effectiveness, feel free to check the books and websites referenced in this article.

To create these management reports, we will be looking at how Team Foundation Server (TFS) can be used to manage an agile project that uses XP like features; features like stories and short iterations.  TFS will keep that information in a database and we will create reports that will keep the information flowing to our customer.

We will look to create 3 reports: a story details report to allow you to print out your stories to post up in your war room, a current iteration report that reports the status of your current iteration, and a breakdown report. 

System Requirements

1.    Team Foundation Server (TFS)

2.    SQL Server 2005

3.    Visual Studio 2005

4.    Crystal Reports XI

Agile Project Nuts and Bolts

To introduce you to Agile, this article will focus on a methodology similar to what I am familiar with.  This is based on a training course from Robert Martin, author of among other titles Agile Principles, Patterns, and Practices in C#.

This article assumes that the reader is familiar with Agile concepts.  We will go over some of the precepts of Agile development, but the reader will need to look into other articles, books, etc. for a real introduction on agile software development.

There are many reasons for utilizing agile methods for your software development.  In our case, we needed to produce better quality software and communicate better with our customers.   The Agile Manifesto has 12 principles.  "Satisfying the customer through early and continuous delivery of valuable software" is the first one and "Welcome changing requirements, even late in development" is the second.  These 2 principles address issues important to my current workplace. 

This article assumes a project that utilizes user stories as part of the requirements documentation.  So a project has a collection of user stories which define the features for that project.  The development team assigns each story a point value by voting how many points each story will take.  This point system is totally arbitrary.  After a few iterations the team will decide what points equal easy, medium hard, etc. 

Each iteration starts with a planning meeting where customers select stories.  Customers are constrained by the number of points the team believes can be done within that iteration.  Once stories are selected, there should be some form of Customer acceptance tests created by the Customers, which the team will code to.  Since one principle of agile is "Welcoming changing requirements, even late in development," new user stories can be added at any time to the backlog of user stories.

This particular version of an agile practice is very close to XP in tracking and selecting the teams focus.  For true XP, things like pair programming would figure in as well.  I also recommend having as much of the team as possible in a "war room."  Having the team working together in one room, without cubicles, during the project really improves productivity. There are studies that prove this.

So for this type of agile project, we are tracking user stories, and point totals for the current iteration.

Using TFS for tracking an Agile process

To create the reports, we will need to have some way of capturing this data.  Traditional agile would suggest having story cards (standard index cards) posted somewhere in your war room.  That and excel spreadsheets can help you track this. 

That does work for many projects, but what about cases where the team is distributed (including customers)?  In that case many people, me included, prefer to have the user story information captured electronically.  If a company is already using TFS, this tool has many ways you can capture this information.

This article proposes using the MSF Agile template included standard in TFS as the basis for your reporting needs.  One could customize his or her own version of this to make it fit agile.  We will not cover that in this article, but you can look at this web article if you are interested in customizing your own template.

In the MSF Agile template there is a work item called a Scenario, which can be used to capture your user stories.  See Figure 1 for an example of what this looks like.

Figure 1

On this screen, Rank can be used as iteration number.  This field is free text, so there are no constraints on that.  On the Details tab there is a field called "Rough Order of Magnitude" which can be used for the point total.  This field is constrained and needs to be modified with the point system you want to use.  To modify existing templates or to create your own, see this article on MSDN.  The title is the User title and the description can include more details to capture more in depth information or links to documents which the team can refer to.

Another benefit of using TFS is that each story has a unique number which can help when identifying which story the team is working on.  With these different fields, which are captured in the TFS database, TFSWorkItemTracking, management reports can be created.   Keep in mind that this is not the reporting warehouse so the report SQL statements that are included in this series could change with upgrades.  The bottom line is that if your servers have a regular backup routine, your database for your project information will be hard to lose, showing another benefit of this method. 

Summary

For this first part of the series on creating agile we went over the basics of how the agile process can work.  We also went over how you can utilize standard TFS process templates with your agile process to help produce reports to help manage your projects. 

In the 2nd and 3rd parts we will go over actually creating the reports in Crystal XI.  Until then, keep producing great software and happy coding.



User Comments

No comments posted yet.

Product Spotlight
Product Spotlight 



Community Advice: ASP | SQL | XML | Regular Expressions | Windows


©Copyright 1998-2024 ASPAlliance.com  |  Page Processed at 2024-03-28 3:01:05 PM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search