Paul Gauthier and I were talking about using more of the information stored in the Team System data warehouse for the "inspect and adapt" aspects of most Agile practices. If you use TFS for managing your Product/Sprint Backlogs, associate source control changesets to Sprint Backlog Items, and use Team Build then you have a wealth of information about your process at your fingers. There are some great reports out of the box with the Conchango Scrum for TFS process template, but there is so much more data to be mined.
Paul's team is just starting with Scrum and we have had many conversations about estimating User Stories in the Product Backlog using Story Points. Most of the groups I coach have to get used to the idea of estimating this way. I always tell them that over time your team will become more accurate with gauging the story point value of individual stories. We talked about being able to go back over time and see how many hours were actually worked against individual stories and using that data to get an idea of how much diversity there are in the actual hours worked over multiple stories assigned the same story point value.
Paul created the great report we are calling "Product Backlog Estimation History". You choose a story point value and a date range, then the report will show you a graph of the number of Product Backlog Items with the same amount of actual hours worked.
Over time you can see trends in how accurate your team is estimating using story points by seeing the variation of hours actually worked. If you see a large variation then you might want to look at this during a retrospective to see why the estimates are no more accurate. You will see some degree of variation naturally, but large amounts can be a symptom of a deeper issue.
There are some great reports that come out of the box with the Conchango Scrum process template for TFS, but I have always had an issue with the formatting of the Product Backlog Composition report.
This report is a great breakdown of each Sprint showing the Product Backlog Items and all the associated Sprint Backlog items. It shows the story points assigned to each Product Backlog Item as well as the original estimated hours versus the hours remaining for each of the subsequent Sprint Backlog items. This is a good report for management that want to see what items are being worked on in the Sprint and now muck work remains to be done. Project managers used to more traditional reporting seem to like it also.
I had a few of issues with the report that comes with the template:
- The Story Points for each Product Backlog Item line up on top of the column for the Sprint Backlog Item's original estimated hours. This makes it look like the total of those hours, which of course it isn't.
- There is a total for the hours remaining for the Sprint Backlog Items, but it is at the top of the column next to the Story Points for the Product Backlog Item. This also leads to the misconception that the Story Points are the total for the original estimates. I also would expect the totals to be at the bottom of the columns, not at the top.
- The rows are separated using alternating row colors, but I rarely print the report with colors so the rows run together.
Paul Gauthier, who works at one my clients, created a new version that addresses the issues above. Click here to download the version Paul has reformatted.
Paul is working on a few other reports that I have had in mind for a while but could not find the time to create (plus I do not know very much about SQL Reporting Services). I'll post those soon.
In the last month I have had two separate clients have issues with how their working directories were setup in their TFS builds. First a system drive was running out of space from a large amount of new projects being built, and second some builds were failing due to some file paths being over the OS enforced limit of 260 characters. These were caused partially because it is not immediately obvious where the working directory for the build server is located when you create them. This post is a quick review of how to manage the working directory and avoid the two issues above.
The working directory is the location where the server will place all the source code for a TFS project's build. It is logical to think that since you are asked to select a workspace during the creation of the build definition, that the build would use the local directory set in that workspace. That is not the case.
If you create a build with most of the defaults the working directory will be a temp folder under the Local Settings directory for the user that the service runs under (which is usually TFSSERVICE). You can see this is the buildlog.txt screen shot here.
So by default all the source code for all the builds will be on the system drive (most likely) and will start out in a directory path that can be 80 to 100+ characters deep already giving you not much room before you will hit the 260 character limit.
So you may initially go back to the build definition to point to another directory on another drive with a shorter path. But you will see that while you can set the drop location where the compiled output of the build will go, the working directory is not set in the build definition.
The working directory is actually set in the build agent in the Working Directory field (funny enough). By default this will be $(Temp)\$(BuildDefinitionPath). The $(Temp) is what points us to the user's temp directory under Document and Settings.
So we can change this to point to the directory and drive of our choice to prevent our system drive from being overloaded and hopefully avoid reaching the 260 character limit when the source code is pulled down.
Chris Tullier has created a site on Ning.com called Team System Live. It has a great calendar of events for upcoming in person events, live meetings, web casts, chats, etc. all concerning VSTS and TFS. The are many TFS experts as members already. If you are interested in Visual Studio Team System or Team Foundation Server, sign up now!
I hate re-blogging posts from another blogger, but Brian Harry's post about the new guide for Troubleshooting Installation for Team Foundation is worthy of breaking my rule. A few months ago I was at a client performing an upgrade of TFS 2005 to 2008 and we hit a snag in the middle of the installation where the setup could not configure the SQL Reporting Services web directories in IIS. We spent 4 days on the phone with Microsoft who finally advised us to slick the server and install TFS 2008 from scratch then restore the databases. I have already seen some of the symptoms we experienced in this guide.
It also has some post installation configuration issues I have seen many times. These also pop up after service pack installations or similar events that alter the configurations of any of the supporting services.
Definitely keep this guide handy!
Microsoft has posted an update to their VSTS 2008/TFS 2008 VPC trial image here. This one expires 12/31/2009 so you can get a good years worth of use out of it. These are great for a test environment, demonstrations, or simple a playground to experiment with this software.
First I change few of the labels for the standard fields from the Conchango template:
Business Priority is changed to Business Value since the word "priority" has a certain connotation of order. I also implement a SuggestedValues rule with values ranging from 100 to 1000 with increments of 100 (100, 200, 300, etc.).
Estimated Effort (days/story points) is changed to just Story Points since I really encourage teams to not use days or hours when estimating the Product Backlog. I add a SuggestedValues rule to this field with the Agile standard of the Finbonacci sequence variation (1,2,3,5,8,12,20,40,100). Some clients use the planning poker cards from Crisp, but I do not include 0, 1/2, ?, or the Coffee Break card.
I also change the description on the Conditions of Acceptance section to include "or How To Demo Steps" since I really like using this technique over just a bulleted list of acceptance criteria.
I also add two new fields:
Return On Investment which is a read only field calculated by dividing the Business Value by the Story Points. We use this as additional perspective when ordering the Product Backlog. The value is updated by a web service created using Howard van Rooijen's project template for TFS event subscription end points.
Product Backlog Type which is used many different ways depending on your Agile tool or general philosophy. My version has three allowed values:
- User Story which is exactly what it sounds like. All these entries must fit the user story format.
- Technical Requirement which is for any behind the scenes work like refactoring, building supporting components with no UI, etc. This helps identify which items require functional tests to be created (meaning a User Story) or those that just need to be regression tested with the current suite of tests.
- Epic which is used for placeholder entries. Some people like to use TFS Areas for this but I prefer to put it at the Product Backlog level. It allows stakeholders to throw pie in the sky ideas on the backlog. Our rules specify that an Epic is not estimated, is always last in delivery order, and can never be added to a Sprint until it is broken up into acceptable User Stories with a Story Point value that can be done in half a Sprint.
I also add some new work flow steps:
Ready For Test is something the Conchango template puts at the Sprint Backlog level and I prefer to have this measured at the Product Backlog level. There is some contention on this even on the Conchango forums. My thought is that a task like "Create class to hold search criteria." cannot be tested but its corresponding User Story ("Search Online Catalog") can be.
Failed Test and Passed Test are two optional steps I sometimes put in to follow Ready For Test. This depends on how integrated the testers are with the development team. If they are very integrated and the team is good with simply communicating failed and passed tests verbally or via email then these can be left off. I have had less integrated QA teams that were also not co-located with the team and we found these steps necessary to keep up with test results.
And finally I organize the form a bit to keep it symmetrical and grouped a bit more clearly.
These changes are not necessarily a good fit for every team and I really try to understand the level at which each client can adopt the Scrum processes before we run head first into customization. I have found these changes to bring value to the process for the majority of time.
Earlier this month Microsoft announced its BizSpark program for startup comapnies. This seems like a great program for any privately held company, in business for less than 3 years, and makes less that $1 million in annual revenue. The reason I mention it is that the program comes with a VSTS MSDN Premium subscription and Team Foundation Server 2008 Standard Edition. As I perform more of my TFS/Scrum coaching engagements I get feedback from smaller, new companies about how they cannot afford TFS and this program could possibly help some of them get the software. If you own or work for a private startup, definitely check out this offering!
Yesterday I drove down to Huntsville, AL to present to the local .NET user group. The meeting was hosted in a very nice auditorium on the Intergraph company campus. The majority of the attendees worked for Intergraph who has been recently adopting Scrum and evaluating using TFS for their management tool. I ended up delivering both the "Intro to Scrum" talk in an abbreviated form and then going right into my "Implementing Scrum using Team Foundation Server" presentation. The crowd was very engaged and there were some great conversations afterwards.
I want to thank the user group leaders (Sujata, Jim, Charlie, & Steve) for having me down.
This last week I have been working with a client to create MSBuild scripts for build automation. We ran into various issues and after various web searches and blog mining we got everything working today. Although I am not a big fan of posting links to items that have been blogged about rather frequently, I decided to provide a rundown of our issues and the blog posts that helped us fix them because of the large amount of sites that had wrong or misleading information.
Our first issue was the fact that our applications were built using Visual Studio Team System 2008 targeting both the 3.0 and 3.5 versions of the framework, but our Team Foundation Server was still 2005. There were several posts about creating custom tasks or using Powershell, but the simplest resolution was to simply use the FileUpdate task in the MSBuild script to modify the solution file. This was not actually in a blog post, but in the comments to this one. I would add to this approach that you change it back somewhere after the CoreCompile target fires. I opened the solution on the TFS server itself a few times to troubleshoot some other errors and without changing the file you get the conversion wizard when you try to open the modified solution file.
This worked for our 3.0 projects for our WCF services, but our web application needed the 3.5 version of the compiler due to our use of C# 3.0 syntax such as automatic properties and object initializers. Again there were several posts with various resolutions (some involving create another build server with a modified MSBuild.exe) but most were not acceptable to the client. We eventually called the DEVENV for VSTS2008 directly from the command line to build the web application solution. This worked better than I expected and even itemized build errors in the build log just as if it were part of the core compile. Calling the DEVENV was outlined in several blog posts also, but a fair amount of these had incorrect or incomplete syntax. Finally we found this post that provided the correct syntax and a very clear explanation of why it works. This resolution also helped us overcome the glaring omission of MSBuild support for setup projects.
So after many, many failed builds we finished our build scripts today that compile all of our solutions, build the setup projects, copy the MSI files to a network share, and then use PSEXEC to install the application on our development server. We have a separate batch of build scripts for the different branches in the code so within a few minutes I can deploy any branch of the code to our development server (or local machine) for testing. Even with a few days to figure it out the overhead of doing that manually will save us much more time in the long run.
When I presented at teh Chattanooga user group the otehr night I spun up my VPC image with TFS 2008 and VSTS 2008 on it to run thru my demos before I started. It was then I rememberd that the image expired last week. I set back my system date to get thru the presentation with only one demo (the CI Build creation) bombing out due to the change. Looks like there is a new image out there that expires Dec. 31, 2008.
Posts
