3

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?

Improve this question

2 Answers 2

Reset to default
1

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

Product
   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.

Improve this answer
3
  • 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.
    – Andrew Clear
    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.
    – Brett Maytom PST
    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
4

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

Area paths:

product\version

Iteration paths:

team\iteration

Improve this answer
1
  • 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 that you have read and understand our privacy policy and code of conduct.

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