16 Oct 2008

As I have mention in a previous blog entry I’ve been heavily involved in the Scrum for Team System process template since the start of version 2 and have written the majority of the reports. I have faced, and still do, some challenges while doing this. Some of them have been around how to display the data within reporting services 2005.

Now with the release of Team Foundation Server 2008 Service Pack 1, release in August, this enables Team Foundation Server 2008 to be used on a SQL Server 2008 environment. This will make some of reporting challenges I faced with reporting services 2005 disappear. This will due to major changes that been made to reporting services 2008 like Tablix control and wider Dundas chart controls.

Within this release we have made a patch which will update some of the reports for reporting services 2008. This to fix some of the reporting services 2005 Patterns and Recipes which became visible. I am currently working looking at how Scrum for Team System can make more use of the reporting services 2008 which we will release as an advance reporting pack in the future.

14 Oct 2008

As I have mention in another blog posts; I’ve been heavily involved in the Scrum for Team System process template since the start of version 2 and to coincide with the release of version 2.2; I would like bring your attention to a new tool, which I help to developed, that has been added to this release.

I started creating this tool due to some feedback we got from our beta users for “TaskBoard for Team system” tool. The request was to add a demonstration mode into the application which would show things like swimming lane-view and the following reports: Sprint burndown chart; Sprint cumulative flow as these can be view within the application.

The reason for the request was create the sense of: "Look guys, this is what we are working on, and this is how we are doing", throughout the day, not only during the scrum meetings. This also happen a lot within our projects which they do something similar as well. Another reason for the tool to separate from the Task Board application was to avoid polluting what the Task Board application was suppose to do.

So a new page was added to ScrumforTeamSystem virtual folder called: ReportSlideShow. This will allow a selection of team system project(s) reports to be display by their parameters default values. However the reports don’t have to be scrum for team system only reports there is one caveat: all reports have to exist in all requested display projects.

The report that are which are display is control by configuration file. To see how to figure which reports are display please use the Report Slide User Guide Post from the Scrum for Team System site

Across a user selected time period (defaulting to the current sprint), this report shows the total builds per day broken down by status.

Build Static Analysis and Compile

This displays the number of Errors and Warnings either compile or static analysis the last N number of builds.

Build Unit Tests

Shows the total number of units test run from the last N number of builds. The total is broken down by number status of unit tests for each build.

Last Build Unit Test ResultsThis report displays the list of each test that was run for the last build and shows the result of that build. If the unit test failed it will also display the fail message as well. The last build is taken to be the last build within the data warehouse.

Code Coverage

This report shows the code coverage of and the total of code churn for last N number of builds. The coverage units can be selected between blocks, which is the visual studio default, lines or partial lines.

Build Code Churn

This report shows the total “Code Churn Counts” of the last N number of builds broken down by Added, Modified and Deleted lines. This report also features a drill down option which links to the Build Files reports.

Build Files

This report, which is also a drill down for the Build Code Churn report, will display the files which were in the build or between two builds. The files are grouped by the folder in which they are located within source control and display the number of Added, Modified and Deleted lines for each of the change sets. Also included is the following change set information: Check-in by, Date, Policy Override Comment.

This will show a League table of the Top N number of people on their total number builds of Fail or Successful Builds (using either an absolute number or percentage base). This report will run for a selected period defaulting to the currently running sprint. A successful build is defined as any build which not in a state of failed. (Which is not the same as a successful build.)

There is one caveat: The way in which a build is counted against a person is if their change set is linked to a build. So some people will gain some builds fails even if their change set is actually not the reason why the build failed.

All the reports will have the option to select which build type to run against. Also where the reports allow an N number of last builds they have been limited to the following values 10,15,20,25 or 30.

These reports are not actually link to the Scrum methodology but are helpful tools in the engineering practices. There will be a separate forum for issues and question which can be found here: Engineering Practices – v2.2 Reports

To coincide with the release of version 2.2 of Scrum for Team System, I’d like to bring your attention to the wide range of new reports included in this release. I’ve been heavily involved in the Scrum for Team System process template since the start of version 2 and have written the majority of the new reports and tweaked some of the old ones to improve performance by moving some of the querying to the TFS cube, as well as reflecting user feedback.

One such fix, which can be found in release, was to the burn down report which would show a misleading (but accurate) trend line if the task data wasn’t updated on the very first day of the sprint. (This could also be fixed by making your Scrum Master work harder, but I don’t have any control over that so I decided to tweak the report instead).

Most of the new reports in this release are focussed on engineering practices, which I will cover another blog post; however there is one new report specifically targeted for Scrum called the velocity report.
Velocity is based upon the recorded historical performance of a team, and is a fantastic tool for accurate release planning; for more details please see my colleague Simon Bennett’s blog for more details.