TFS: How to represent the application version that each change request, bug etc will be addressed in

Question

We have recently transitioned from Gemini to TFS for application change control. There is one aspect of TFS I can't get my head around - the lack of a built-in concept of the application version that each work item will be addressed in.

In Gemini every feature request, enhancement, bug etc can be tagged with a version number. If the field was left blank, the item was "unscheduled", i.e. on the backlog. Each version could be flagged as either released or not. Reports could be then created listing the issues addressed in each released version, i.e. release notes, and the issues to be addressed in future versions, i.e. a roadmap. I was completely happy with this!

Now in TFS I can't find any built-in concept of version. It seems like there are 2 ways to represent version:

As a parent item in the iteration tree, e.g.

Version 1.0.0

• Sprint 1
• Sprint 2
• etc

Version 1.1.0

• Sprint 3
• Sprint 4
• etc

As a parent item in the work items tree, e.g.

Version 1.0.0

• Requirement 1
• Requirement 2
• etc

Version 1.1.0

• Requirement 3
• Bug 4
• etc

The latter approach looks better because it allows versions to be worked on simultaneously (e.g. a major release will be worked on at the same time as bug-fix release).

So what is the recommended approach to managing work by version?

Finally, with the version property not actually being present in the work item itself, is it possible to make reports on issues addressed in each version?

Answer 1

For now I am going to use iteration path to capture the version number. This doesn't lend itself so well to managing development on different versions concurrently, but we are trying to get away from that practise (i.e. be working on the next release while simultaneously working on multiple bug fixes to past releases) and adopt short release cycles, i.e. a more linear path, so maybe that is a good thing.

Earlier I though Area Path might be a good place to put Version, but its too valuable as a way to split up a huge application into parts to sacrifice for versioning.

Answer 2

1. Tags (TFS 2013+) are the easiest way to append metadata such as build#. (same as mentioned above.)

2. The CMMI Process Template > Requirement and Bug Work Item Types have an "Integrated In" field that links to TFS Builds for direct correlation from requirement to build# [to related code changes] [to related test cases [to related test results]]. Note you must select from retained TFS Build system builds (that have not been deleted). This hard reference drop-down limits this field significantly over time or if you use a different build system. (That and build versioning are entirely different discussions :-).) The Build CMMI template fields have been there since TFS2010.

3. Create a custom field in your User Story and Bug work items. BuildImplementedIn or similarly named field would do. Creating custom fields is not hard in TFS. You will need a Team Project Admin or possibly a TPC Admin to make the customization if you aren't already an admin.

p.s.: Sorry for the late reply. I posted this answer in case others still have the same or similar question.

Answer 3

You could use the area field.

We use that one for product name (we maintain multiple products) and then version goes into the description of the story, but you could use the area field for versions.

Another possibility is to use tags at the top of the Product Backlog Item.

Btw, I agree that TFS is lacking a few important fields (custom fields)