Work Item Check-in Policy for BA’s, PM’s, and Testers?

Team System today provides developers with the ability to associate their code with work assigned to them in the form of Team System work items.  This is done via the work item check-in policy that you can enable on your project.

There is a lot of benefits of using check-in policies.  First of all, this particular check-in policy gives us traceability between my work item and my code.  This means that I can go to a work item that we associated with a check-in and drill down into the details of the changeset.

You also get some great additional information when you use Team Build – giving you a report of the associated work items for the code that was changed in the latest build – essentially, a “what is new with this build” report automatically.  Another benefit is workflow – as you can trigger workflow progress (for example marking a task as resolved) when you associate the code with that task (note:  this will all depend on the workflow definition of the work items in your team project).

It takes quite a bit of discipline for developers to adhere to the process of associating a check-in with one or more work items.

Wouldn’t it be great if we could expect the same thing from those on our team who produce documents and not code as project artifacts?  Today, the default advice is to use a Team Project’s associated Windows SharePoint site to store all document artifacts.  There is a bit of a disconnect with this method it seems, since SharePoint doesn’t version documents like we version code, and it makes it very difficult to get traceability between work items and the resulting documents.

Wouldn’t it be great if Business Analysts, Manual Testers, Project Managers (etc – essentially those who produce document artifacts in some form) get to play by the same rules as developers?  Well, if you get the latest Team System Power Tools from Microsoft you can get just that!  One of the features that the Power Tools installs (not by default by the way, you need to do a custom install of the tools during setup) is the Windows Shell Extensions for Team Foundation Server.  What this means is that you can use your Windows Explorer to work with TFS source control. 

After you install the TFS Power Tools (again, make sure you do the custom install as Shell Extensions aren’t installed by default) – all you need to do is ensure your BA’s have a workspace mapped appropriately and Bob’s Your Uncle!

Once the workspace is mapped, simply navigate to the local path  and you will see the Shell Extensions come alive.  For example, in the TicTacToe project I created a folder called “Documents” using my Windows Explorer under c:\Dev\TicTacToe (that’s where the workspace maps that project to on my local drive).  I then right clicked on the folder to see the Shell Extension in action …

I then click “Add” from the Team Foundation Server menu to tell Source Control that I want to add this to my project.  Then I can right click again, and this time choose “Check In…” from the Team Foundation Server menu to bring up our handy dandy check-in window (use the exact same process for documents as well).  Once you see the check-in window you will see that all of the check-in policies are enforces, and if you have the work item check-in policy enabled – you will be forced to associate the document with a work item.

I think this is a great idea for a few reasons.  First, it keeps everything together – not spread across a bunch of different storage mediums.  Second, it allows me to version my project artifacts together – eg:  I can apply a label across my entire project – including documents (too bad I can’t version work items like that as well).  Third, it makes it dead simple to maintain traceability between work items and document based project artifacts, even though it is through a changeset link instead of a direct HTTP link from a work item.

If your Testers, BA’s and PM’s start complaining about the extra work – remind them that developers must do this every day and that a little bit of discipline goes a LONG way.  Besides, they should ecstatic based only on the simple fact that they no longer need to use SharePoint web interface to get to their documents – all documents will be local as far as Office is concerned.  Happiness I guarantee.