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.

An Good Agile Team is a Disciplined Team

Since last year I have been at two different development shops that were in various stages of adopting Scrum. At the first I was the development manager and initial Scrum Master for a medium sized team that was moving from a waterfall/cowboy process to Scrum. Most recently I have been consulting with a smaller company that had previously loosely adopted Scrum, but has been bought by a larger company that has a more structured methodology. It has been a very educational experience.

One thing that I have learned is that a development team that wishes to get the most out of adopting Scrum must be a very disciplined team. It is sometime a misconception that agile methodologies are basically "the inmates running the asylum", but agile (and Scrum in my experience) requires a more mature and self-reliant team than waterfall. Scrum team are "self organizing" and are given almost total freedom to get their job done during each Sprint. They are left to determine what needs to be done, who works on what task, the approach for each item, etc. often with little to no outside influence.

This is quite a big responsibility and I have seen many people (and I include myself) struggle with it. Less mature developers may dive into a technical task and be oblivious to how their task relates to the project as a whole. Often they do not take advantage of the Daily Scrum meetings to get a good sense of how the team is progressing towards the current Sprint goal. These developers will often under estimate tasks and their deliverables will tend to be less on target.

Scrum Masters can fall into old habits also. As a Scrum Master I tended to want to "lead" the team rather than facilitate the team leading itself. Sometimes this was "muscle memory", but often I had to provide a more hands on approach when my team would start to drift away from the goals of a Sprint. I had to make a concentrated effort to let go and allow my team to run itself. I also am guilty of getting off track in the sacred Daily Scrum meetings. My team takes great joy in using my own phrase "Don't tell me about the pregnancy, show me the baby." when I do this.

I think that most every developer really knows what must be done to create a solid software solution, but what we struggle with is the discipline to execute in our daily activities. It is often easy at the beginning and then gets decidedly harder as the pressure increases. I personally struggle with this and am trying to make a real effort to make myself adhere to the principals that I believe make me a better developer.

Just this last Sprint I found myself continuing on a task that we had time boxed to a few days. At the end of the time period I was very close to wrapping it up and decided to extend the time period. Each time I got "close to finishing" another issue arose and I extended the time period again. I did finish the task and the result will greatly benefit the team, but other tasks were sacrificed. I also had to admit to myself that if another member of the team had done something similar, as the Scrum Master I would have probably called them out on it. It was another lesson it how to be more disciplined in my approach.

My hope is that each day I gain a little more experience and a little more practical approach to how I adopt (and sometimes DON'T adopt) agile/Scrum philosophies. That way the next day I become a more disciplined developer.