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

2
votes

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?

3
tfsscrumcmmi
Can't you branch out from the main branch for a new version? And maybe branch out to a "release" branch after a release, where you can do your production fixes on? – Joris Van Regemortel
Yes - I do that in source control, but I am not talking about that - I am talking about managing the work items. – Laurence
Iterations are used to specify when a Task should be implemented or a Bug fixed by a developer. This will be easier to maintain than the work item structure you suggested as second option. I can't see your reason why you are not able to work simultaneously on the versions, because working on the major release and bug-fixing the old release could be done in the same sprint. Or if you don't want to, you can create a parallel sprint (same timeframe) for the bug-fixing. – MikeR

3 Answers

1
votes

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.

1
votes

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.

0
votes

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)