TFS For CRM Development Management

Sometimes on CRM projects you get asked to do things outside of your usual routine. On my latest project I am setting up Team Foundation Server (TFS) so the development and testing teams can use it to:

• Track the progress of a cycle of configuration, followed by a cycle of development
• Manage the development tasks for the modules they are creating
• Trace the individual business requirements against the development modules
• Track the testing of the business requirements to ensure they are met as the modules are completed
• Track issues discovered against the development modules for follow-up
• Review who is checking in code

Previously, I had only known TFS for source control but it turns out it has been extended in the last few versions to do a lot more. I am working with TFS 2010 but, I am reliably told, TFS 2013 goes even further to make TFS the one-stop shop for development management.

What Information Can We Capture?

TFS has a number of ‘entities’ to manage development. These are:

• Areas
• Iterations
• Work Items
  • User Stories
  • Tasks
  • Issues
  • Shared Steps
  • Test Cases

Areas are a bit like the Subject entity in CRM. The are used to categorize Work Items and are self-referential so an Area tree can be setup (this is done from the Team settings area of Visual Studio).

In my case I created Areas for:

• Deleted Items: There is no obvious way to delete Work Items, so I unlink them from everything and mark them with this Area
• Requirements: This is a category for all Work Items which define a business requirement of the system
• Development Modules: The self-contained modules being developed for the CRM system
• Development Tasks: The steps a developer will follow to complete a module

While I could make a hierarchy of these areas, I saw no benefit in my case and left them unlinked.

Iterations are the build cycles. In my case, I have two cycles: a configuration cycle and and development cycle. The only information we capture on the Iteration is its name and whether it is part of a hierarchy (like Areas, Iterations can be structured like a tree).

The Work Items are, in some ways similar to CRM Activities in that, while Activities are treated as a group in some ways e.g. when constructing queries, the sub-types also get individual treatment, specifically when storing information.

A User Story is something we are working to achieve with the development. So, for me, this covered two aspects: the development modules and the business requirements.

Here is the User Story form in TFS.

For my purposes the following fields were useful:

• Title: To describe the development module or business requirement
• Assigned To: To set the person building the module or the person responsible for testing the business requirement is met
• State: For specifying where the module/business requirement testing is up to
• Area: For classifying whether it is a development module or business requirement
• Iteration: For specifying which cycle the module will be developed in or the cycle the requirement will be met in
• Details: A broad description of the module or the details of the business requirement
• All Links: This is when we link the various records together, which we will cover later

Tasks are like their namesake in CRM; they are something to do. In my case these were perfect for listing the steps in the breakdown of work for each development module.

Here is a Task in TFS.

Again, we have the Title, Assigned To, State, Area, Iteration, Details and Links areas, as with User Stories, but we also have:

• Activity: which defines the kind of Task being done

• Start Date and Finish Date: To define when the Task is expected to be actioned
• Effort (Original Estimate, Remaining and Completed): To manage how the developer’s effort matches to the original estimates and to give an indication of how complete the Task is

Issues, not surprisingly, are for recording problems. In my case these are the bug reports, held against a development module for the developer to action, once testing has been performed. Here is the form.

This is similar to the User Story form and the fields are used in, essentially, the same way.

Shared Steps are common testing steps which can be used across multiple test processes. In my case, the testing of a business requirement required only the capture of a pass/fail with an Issue raised in the case of a failure so I did not use these.

Test Cases, surprisingly, I did not use. Mainly because, while it is possible to create a Test Case within TFS, it is not possible to create Test Case steps; these are created in Microsoft Test Manager (MTM), a separate product and automatically brought in to TFS. Given my simple test requirements, I avoided using Test Cases with the pass/fail being recorded via the Status of the business requirement.

Linking the Entities

In the case of Areas and Iterations, these have a 1:N relationship to Work Items. For the Work Items themselves, any Work Item can be linked to any other Work Item in a way similar to Connections in CRM. This means all manners of structures can be created in TFS. The key consideration in determining the right structure is working out what reports are likely to be generated from the system. In my case, the structure was like this:

So, for example in ‘Iteration 2’, the development iteration, we develop an SMS Module which meets the business requirements regarding the sending of SMS from the system. The tasks for the module are defined and, when the system is tested, issues are logged against the development module for the developer to action.

Within TFS, we now have a one-stop shop for the progress of development. We can open up the development module record and see all related information. By enforcing a policy of associating a Work Item to every code check-in (part of the team setup) we can also see the code being checked in from the development module record.

My Departure From the Norm

While a reasonably sensible structure, this does deviate from the ‘norm’. Generally, the development tasks come under the business requirement (User Story). For me, there were over 1,000 business requirements so this meant a lot of bookkeeping for minimal gain. The only consequence of my approach is some of the out of the box reports, which assume a certain structure, will not work quite as expected.

Reporting

There are three main approaches to reporting with TFS:

• Queries
• Excel
• SSRS

Queries are quite easy to set up and work very much like Advanced Find queries. You are limited to the one entity but, for my purposes, it was sufficient.

From Visual Studio, you can also export queries to Excel. This option also allows for republishing back to TFS, which is great for mass-editing.

Finally, is those are insufficient, SSRS reports can be written as the information in TFS can be queried via SQL.

Conclusions

If your development team is already using TFS for source control, consider also using it for development management. The developers can remain in the products they are used to (Visual Studio and TFS) and the project manager can gain visibility of progress. Also, if you have geographically separate groups developing, this provides a common place to review progress.

Finally, I would like to thank the ‘Davids’ (David Watson and David Jansen) of Microsoft for walking me through TFS. Without their patience I would have have half the knowledge and twice the frustration with the product and their generosity of time is greatly appreciated.