One of the new (and awesome) features of TFS 2010 is that you can create deep and complex relationships among work items of various types. This is needed to create rich project tracking and reporting. There isnt a TFS 2010 for Dummies book out yet and I needed a simple way to explain this. Pretty pictures to the rescue!

Here is a visual of how the work items are related. It can be complicated but it is this relationship structure that empowers the whole system. The work items under a user story (children) are either test cases or tasks. Tasks are for when someone needs to do something. Test cases are for things to validate for that user story to be functionally complete. As the tasks are completed, code is being written and functions start to work in the application. When all of the child tasks of a user story are completed, then the user story is code complete… meaning it can be tested. At this stage a tester will look at all of the child test cases of a user story and start to try them in the QA environment. As they find issues the will create bugs which are related to the test case (and associated user story). When all of the test cases are complete with no bugs and all of the tasks are complete it means a user story is complete (and should be working). Also notice there can be another dimension beyond parent and child, that of predecessor and successor. This is used when one task needs to be completed before another can start. An example of this is that a web page’s UI needs to be designed before it can be built. This is useful to determine the calendar date of when a user story will be complete. You can export all of this data to Excel and MS Project if you like.

A couple concepts that are not represented in this diagram code check-ins and builds. As code is checked into TFS it is associated with development tasks. Check-ins are rolled up into builds. Therefore you can garner all sorts of interesting data; bugs in a build, completed user stories in a build, work completed in a build…