Visual Studio Team Services continues to receive improvements on a 3-week cadence. The latest deployment included a slew of improvements to work item tracking including the ability to move work items between projects and even change their type in the process. Another interesting feature is the ability to add pick-list fields to your existing work item types.
I think that the ability to customise work items is a really valuable feature and I can see it being put to good use. Use of work item tracking exists on a spectrum. I see teams that use it largely as intended and often use the out-of-the-box templates with very few tweaks if any. Others will sometimes bend VSTS to their will which is also fine, provided their process is delivering for them. Other-times I see VSTS, and work item tracking being abused for things that it was probably never designed for.
One of the common anti-patterns that I've seen is teams that automate the creation of work items from some external source, where the rate of creation and the nature of the data isn't really a good fit for VSTS.
I like to think of work items as representing work (the hint is in the name). To do work, you need some contextual information like a title and a description in the simplest. As your perform work, you might want to track other items, such as the status of the work, who is performing it and more. Eventually the work is complete and can be closed out. This description works for almost all of the out-of-the-box work item types.
Where I see teams going wrong is injecting static reference data into the work item store. Remember the automated creation of work items I mentioned before? Well, lets say that your application sends exception data to a central location for analysis. It is absolutely capturing this telemetry and storing it for analysis, but I wouldn't recommend creating a work item for every single instance of an exception that your code generates - yet that is exactly what I've seen some teams do.
Here is a simple test you can apply to your own usage of work item tracking to help identify whether you might be better off using some other data store.
- The work items you create are reference data, that is they don't represent work with a beginning, and end and some kind of tracking.
- The work items are being created a rate where the humans in your project can't read, understand and respond to them.
- The work items tend to contain duplicates (e.g. storing details for each instance of an exception).
I think that some people use work item tracking like it is a general purpose relational database. A better approach would be to externalise all this data and simply link and refer to it from work items within VSTS.