My Latest Favorite Feature of VSTS 2010

As I explore the VSTS 2010 CTP, I find more and more to like about it. My latest favorite is the ability to setup true work item hierarchies. You could fake this with linking work items in 2005 and 2008, but now these types of relationships are first class citizens.

You can now click on a work item in a results view (or select multiple work items) and the context menu now has an option to 'Link to An Existing Item'.

This brings up a dialog that allows you to choose a link type (from choices such as Parent, Child, Predecessor, etc.) and then shows you a visual representation of the link type.

There is also a new results view that shows these hierarchies. Another great thing about these views is the ability to drag an item under another item and it automatically make the parent/child links.

My only issue is that this new 'tree view' style results view is a little murky in showing items under another item. In the screenshot above you can see the tasks and bugs related to the user story but there is not a very clear distinction. Hopefully they will fix this in the next release.

This is something I have wanted for a long time to help with Product Backlog and Sprint Backlog management inside TFS and I cannot wait to start working with it for real!

New Product Backlog Estimation History Report for Conchango Scrum TFS Template

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.

Reformatted Product Backlog Composition Report for Conchango TFS Template

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.