This is a TFS-specific question. If this is inappropriate for this site, let me know where I can ask it. I initially posted it on StackOverflow, but didn't get much of a response.

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?

2 Answers 2


TFS has the concept of iteration, which is a hierarchy of release points. It is pretty flexible and you can break it down to something like

   Release 1.0
     Sprint 1
     Sprint 2
   Release 1.1
     Sprint 3
     Sprint 4

You can even put teams in them. When you crate a work item, you simply allocate the work item to the the correct iteration. If it is not to be released, then simply change the work item's iteration path to the correct new iteration as TFS tracks history.

As the workitem (requirement, bug, test) is associated in a hierarchy, you could write a query to find all work items "UNDER" Release 1.1; this will include all child items. Using a combination of Area, Iteration and state you are able to create some pretty powerful queries.

  • Unless I'm missing something, this method precludes a sprint where you do release 1.0 support work and new work on release 1.1. Really only feasible if you only support a single release in production at a time. Jul 26, 2013 at 8:10
  • Then adjust the area hierarchy to suite this. Sprint 1 - Release 1.0 and Sprint 1 - Release 1.1. Alternatively create a custom field in TFS to indicate the release on the PBI. Jul 28, 2013 at 0:03
  • 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.
    – Laurence
    Aug 1, 2013 at 8:38

I like using area paths for this. It allows you to do work in parallel, without breaking the iteration model.

Area paths:


Iteration paths:


  • Thanks! I'll try this out and mark this as the answer if there are no better suggestions.
    – Laurence
    Jul 29, 2013 at 9:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.