On my current gig we are using TFS to manage project lifecycle, version control, and quality assurance. While there are still quite a few enhancements we are waiting for in much anticipated service pack, the current version is humming nicely.
We found that all the templates had things we liked, and things we didn't like. Those that collected more information were too bulky to use. Those that were simply to understand, didn't collect the data points we required. Which brings us to customizating the work item templates.
For myself, the key to understanding work items templates (WITs) was just mapping Fields to Controls, and then worrying about the Transitions seperately. The States got in the way in most cases, because I tend to think that most information should be configured by the user not the system. I recognize that will be taken as a religious statement by many, but oh well.
To start with, we mapped all the data for our modified WIT into the most appropriate field. In many cases, we simply borrowed the fields from other templates and then used them for our purposes. After we had all the fields which represented the data we wanted to collect, we were able to figure out which ones had information displayed and how it looked on-screen. This was pretty straight-forward and totally subjective.
With the data being collected and used on-screen we were then able to get fancy by using Transitions to restrict input, validate states, and in some cases, default some data. We only used States in a few situations.
If you'd like to see our modified WITs, shoot me an email.
Why didn't I use the process editors? Because we were shooting for the lightest possible learning curve, smallest number of adjustments, and quickest turn-around. If you, like me, just have some work to get done and want to start collecting some data, I advise steering clear of the fancy tools too. Sometimes the simple approach really is the best.