Visual Studio Team System is extensible.  For work item tracking that means you have the ability to define your own work item types.  One person’s bug is another person’s defect, requirement, feature, risk, issue, change request, or task.  In doing the design, we decided to first be capable of defining work item types in XML and then using that XML definition to instantiate a work item type in the team system database.

The design goals of the work item type definition language (WITD) were:

·        Extensible - to accommodate future functionality

·        Simple – the basic language should be simple to understand and produce

·        Human readable – users should be able to type in simple WITDs and have them work without having to resort to specific design tools

And, of course, the fact that the information can be stored in an XML file makes the WITD shareable and versionable as well.

So, what are the core elements that make up a work item type?

First you need to identify the work item type from others.  This leads to the obvious name and description:

Secondly, you need to define what kinds of data you want to collect.  This is done by specifying a set of fields.

Thirdly, you need to define the workflow.  That is, the states and legal transitions between those states.  This example shows the simplest state transition model we support one state, one way in, with one reason for being.

And finally, you need to define how this information is presented to the user.  This is done in the form layout section of the WIT definition language.

And that is about it.  You may wonder, how do I define the business or rules of behavior for a work item type.  These are also defined in the work item type definition language as rules associated with fields and scoped by state and transition.  But I will leave that for another post.

As always, thoughts, comments, concerns, and especially improvement ideas are very welcome.