One of the problems that we are facing is that it has become a little too easy for project managers to create requirements off of e-mails.  Because of this, we are getting a proliferation of TFS work items.  It would be a huge help if an option was available to add as an attachment an e-mail to an existing work item.  Ideally, this should be the default option.

This is an interesting point. From your experience with this problem, would it be more beneficial to expose this from the mail itself or from the work item?  The difference is slight and only in how the UI exposes the functionality. 

If it was exposed from the mail itself, one could imagine the UI being something where you searched for a particular Work Item to attach the mail to.  If it was exposed from the Work Item the UI would be something where you searched for a particular mail item.

Which path were you envisioning?

Cheers,
~Joe

Definitely, from the e-mail.  E-Mail still rules the roost as the communication medium for our company and I am sure for other companies as well. The TFS work item is more of the "work order" under some workflow process that is used for tracking and reporting - TFS will really never be able to replace e-mail as the collaboration medium.  What we have happening is that the people (project managers specifically) don't want to lose info contained in the e-mail so the easiest thing to do is create another work item. In some respects, this is causing more problems that it solves because we have a proliferation of data across work items and no single source of record for a feature. I keep on having to prune the work items and copy the data from the one work item to another related work item and close out the new one as a dupe. Its great to capture "work items" in TFS but if TFS turns into the town dump, TFS and TeamLook begin to lose value.  It seems to me that because it is so easy to capture the data in TFS the argument is being made that we don't need to write requirement documents anymore.  I have even proposed that we shift away from TFS and try to leverage our WIKI for this type of thing.  Anyhow, I can't force anyone to write documents but at least want new info coming from e-mails attached to existing work items. So, it would be cool if when I am looking at an e-mail, I can run some query that brings back relevant work items whereby I could then stuff info from the e-mail into the work item either as a comment or attachment.  In some cases I would say that TFS comment would be even better than an attachment as it is easier to view from the work item.  In would be awesome if TeamLook could even propose possible matches for me (ala Google).

Not sure if you guys ever used the open source issue tracker Scarab (http://scarab.tigris.org/) but one thing that was really cool about that product was that you could instruct Scarab to, before it persisted an issue, was have a look for a duplicate work items based on information submitted.  It would then ask you if you wanted to attach your info to the existing item or create a new one. Similar thing is being done with the JetBrains (http://www.jetbrains.com) support system.  Basically what JetBrains has done with their tool (ReSharper) is that when Resharper throws an exception the tool phones home and the support system either attaches the exception to an existing work item if there is a match or creates a new one.

Same thing here - we need it to be easy for users to route the data to the appropriate work item as follow-up info if this is indeed related to an existing work item.  Only create a new work item if absolutely necessary.

It all comes down to clean, usable and organized information.

Before I dive into trying to address the issues you are experiencing, I’d like to thank you for providing this very insightful feedback.  It is very exciting to see the level to which you and your team are using TFS Work Item Tracking and TeamLook.  Not only is it fantastic to hear about your experience, but the feedback helps us prioritize scenarios/features for future versions.  This is especially true with your feedback in this post.

In order to structure my response, I’ve broken down the comments you made into paraphrased sections. 

1.       Email rules at your company and most companies as a comm/collab medium

I couldn’t agree more with you on this one.  Email is incredibly successful for many reasons: it’s free-form, directed to one or more people, leverages the store and forward mail server, among many other reasons which enables the generally flexible system.  It just works.  For these (and other reasons) it is here to stay.  This is one of the main reasons we thought TeamLook would become so relevant to teams looking for the benefits of TFS Work Item Tracking.

2.       Work Item Tracking (WIT) as a Work Order System under Workflow- TFS will not replace Email as a Collaboration Medium

This comment identifies one of the biggest values of WIT and difference between WIT and email.  Work Items have workflow associated with each item, whereas once an email is sent to the recipient, it’s up to the sender (or someone else) to follow up with the sent mail item.  WIT makes this much easier.  I agree with your description of WIT as a “Work Order System” and believe that this defined workflow will eventually be a significant enough factor to motivate people to learn more about the Work Item Types and even customize them for reasons other than Bugs, Tasks, and even Features and Change Requests (which is what I’ve seen most customizations so far).

One challenge that arises with the use of Work Item Tracking is that users need to know when a Work Item Type (or with your analogy, Work Order) is relevant.  “When do I create a (insert a Work Item Type) Work Item?”  This is easy with Bug and Task because most software Devs, Testers, PMs understand the associated workflow with these Work Item Types.  We wouldn’t ask the service person who changes motor oil to add windshield wiper fluid to our car, unless we’re at Jiffy Lube! J  Jiffy Lube happens to do both as part of their service offering (or process).  What I mean is that it’s a function of “process normalization” (or definition).   I’m not only talking about the process defined as workflow inside a Work Item Type.  I’m also talking about how Work Item Types relate to each other.  Every team member needs to be educated on when to create a Work Item.

3.       PMs don’t want to lose information -> dump information into Feature Work Items

a.       Results in no single source for features

b.      TFS becomes the town dump

                                                               i.      Lack of structure

                                                             ii.      Difficulty of pruning

Emails have a fractional number of fields compared to most Work Item Types.  This means that creating a Work Item from an email will require some processing and structuring on the data in the email.  Today, we have a simple transformation between the email and the Work Item Type which can be customized in the TeamLook Options dialog.  In the future, we will be doing more extensive processing, parsing, and searching when doing the transform.  You’re right; the pruning process you’re experiencing is frustrating and should be replaced by an automated process.  It will.  Now that we have laid the foundation for this parsing/processing with the current version of TeamLook, we’ll be able to provide this functionality in future versions.

4.       Ease of capturing data results in arguments for not writing requirement document

This brings up some very interesting points.  As you might know, we’re currently working on releasing the next product titled ‘TeamSpec’ which is all about team documents (including requirements documents, among other types of Microsoft Word documents) in the context of TFS Work Items.  One of the scenarios we’re enabling with TeamSpec is the ability to create documents based on Work Items.  This way, those people who want to work in the Work Item list/queries world can, and those people who want a document view/representation of those Work Items can also.  One of the biggest problems with requirement documents is that they’re difficult to update and end up becoming stale.  With Work Item Tracking, you get the benefits of the item structure.  With TeamSpec, you’ll be able to create a document from WIs and benefit from Microsoft Word richness of layout, language, and other features while staying in sync with each Work Item in the TFS.  Another scenario of TeamSpec is to create Work Items from portions of existing documents.  We’re very excited about what TeamSpec will do to make Work Item Tracking even more relevant.

5.       Proposed to shift away from TFS and leverage Wiki

a.       To remove redundancy and noise

TFS Work Item Tracking is great because of the workflow, structure (fields), revisions, and also because of the centralized repository.  Wiki definitely gives you the centralized repository since all content is stored directly in the Wiki and manages revisions, but like email is free-form/unstructured which ends up requiring manual structuring.   I love Wiki, however, it merges both the ‘View’ and the ‘Data’.  In some (and definitely not all) sense, “Wiki is to Spreadsheet, as Work Item Tracking is to a Database.”  Of course, there’s more to it, but I think that may summarize my point.

6.        While looking at an email, find work items related to the email

We will definitely have an improved transformation between email and Work Items!  J  Search is a big part of our next version of TeamLook.  We'll definitely have Work Item matching from the email.  I also think it's interesting to find related communications when looking at a Work Item.  We have to do both J.

7.       Ultimately, create a WorkItem only when necessary

Ultimately, any tool should not allow the user to misuse the tool.  After all, that’s exactly why Team System is such a valuable software engineering platform- the tool enacts the process.

I look forward to learning more about the way you/your team uses TeamLook and Work Item Tracking.

Thanks,

Juan