TFS API: Work ItemHistory

One of the tasks I had while developing my own version of a Sprint Task Board was to note each work item’s “staleness”. This meant that for any Sprint Backlog task that was in a state of “In Progress” or “Ready for Test” I needed to know the last time its Work Remaining field had been updated.

The Team Foundation Server API provides an easy object model for iterating through a work item’s history. Each WorkItem has a Revisions collection that holds individual snap shots of the work item each time it was updated. The Revisions in the collection are in order or earliest to latest, but there is also a Rev property for each one that is the sequential order. Each Revision has a collection of Fields for each field, both the common system fields and any fields added from a custom process template. When you access an individual Field in the Revision you can see what the original value was (OriginalValue) versus what the value was changed to in the revision (Value). If the field was not changed the values are the same.

Since this is the very first time the work item was saved the OriginalValue property on all fields is null. The ChangedDate is the date we saved this particular revision and the RevisedDate is displayed as the maximum value of the DateTime type since this particular revision has not been revised yet. If we edit the work item on June 3rd the Revisions would look like this:

The RevisedDate for Revision 1 is set to the ChangedDate for Revision 2. The fields for Revision 2 now have their OriginalValues populated with the appropriate values from Revision 1.

So based on the examples above, if we want to know the last time a specific field was updated you would look for the “System.ChangedDate” field’s Value for the latest Revision where that field’s OriginalValue and Value properties are not equal. Here is a LINQ query that would accomplish this for the “Work Remaining” field (this field is an extended field that comes with the Conchango Agile Process Template).

One thing to remember when using the Work Item object model is its effect on performance. Not all fields are loaded initially so depending on how you access the WorkItemStore you may incur additional round trips to the server. This MSDN article does a good job of explaining how this works and what your options are to increase performance.

Conchango's Sprint Task Board

I wanted to thank Crispin for giving me the heads up that Conchango has posted two video demos of their upcoming Sprint Task Board application. As I stated in my last few blog posts, I had been working on something similar but where Conchango has dedicated development resources, I had only a few spare hours here and there between work and handling the new baby. I look forward to the release of this application and will post a review as soon as it is out. I did learn a good deal more about the TFS API while working on my own pet project and I am working on some more in-depth technical posts in the next week or so.

Sprint Task Board Update

I wanted to clarify that the Sprint Task Board project I mentioned last post is by far not an original idea. It is simply a side project for me to create a version that does exactly what I want it to do. There are various other versions of this in Scrum management products like Mingle and ScrumWorks. Conchango has even hinted at one for Team Foundation Server in a reply to one of my forum posts.

Working on this has helped me get deeper into the Team Foundation Server API and I will post soon about some interesting discoveries in the work item history objects.

Sprint Task Board

With the arrival of our new baby I took a few weeks off. During the late nights I started fiddling around with creating my own virtual Sprint Task Board to emulate the physical sticky note boards most scrum (and other agile) teams use. I have always like the immediacy of the task board, but never could relinquish having the data digitally rather than physically. I am not an agile purist plus my current team has some remote members and a physical board would not work for us. I have created the initial draft as an ASP.NET web page which I plan to port to a WPF extension inside of Visual Studio 2008. This rough version allows you to view the current sprint tasks grouped by either the Product Backlog Item it is associated with or the Assigned User. The IDs of the work items link directly to Team System Web Access so that you can view the details. I plan to start refactoring this into an actual application soon and possibly submit it to CodePlex.

The color coding is based on when an "In Progress" or "Ready for Test" task's Work Remaining field was last updated. The scale goes from green to red according to how "stale" the work item is. Work Items with an open Impediment are clearly noted. This should provide a good overview of the sprint's health at a glance.